Discussion:
[KPhotoAlbum] load-performance and startup-performance
Robert Krawitz
2018-07-07 22:40:33 UTC
Permalink
Has anyone had a chance to play with these some? I'd like to get this
merged; it will really help people IMO.
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Angel Lopez
2018-07-08 07:55:28 UTC
Permalink
Dear Robert,

I have used it and I can really fell a great speed improvement. Thanks a
lot for your work.

The only weird behavior I have noticed, is that during reviewing
photographs, if I zoom into one by dragging a rectangle with the mouse,
then it makes zoom like 4 time more and at the upper left corner. If I
press "." to go back to fit into window it shows a 4x zoom at the upper
left corner again.
This seems to happen on some images only. (I think only on some .cr2 files)

Regards.


______________________________
----------- Angel ------------
Post by Robert Krawitz
Has anyone had a chance to play with these some? I'd like to get this
merged; it will really help people IMO.
--
*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Robert Krawitz
2018-07-08 13:33:42 UTC
Permalink
Post by Angel Lopez
Dear Robert,
I have used it and I can really fell a great speed improvement. Thanks a
lot for your work.
The only weird behavior I have noticed, is that during reviewing
photographs, if I zoom into one by dragging a rectangle with the mouse,
then it makes zoom like 4 time more and at the upper left corner. If I
press "." to go back to fit into window it shows a 4x zoom at the upper
left corner again.
This seems to happen on some images only. (I think only on some .cr2 files)
I don't see how that would be connected with what I did; it didn't
(insofar as I know) touch that. Can you reproduce it with the mainline?
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Johannes Zarl-Zierl
2018-07-11 23:45:47 UTC
Permalink
Hi Robert,
Post by Robert Krawitz
Has anyone had a chance to play with these some? I'd like to get this
merged; it will really help people IMO.
I've reviewed and merged the rest of the load-performance-stable branch now. I
have to admit that I did not put too much scrutiny on the OptimizedFileList,
though. At this point I think the feature is ready for a wider audience ;-)

For the record, two minor issues remain that need fixing before the next
release:
(1) there's an unused member variable creating a warning message
(2) the implemenation of OptimizedFileList should be made less linux-specific

I'll fix (1) some time this week, but with (2) I'll probably need some time to
get a FreeBSD VM set up (I don't want to think of possible Windows compilation
for now).

See also:
https://build.kde.org/view/Extragear/job/Extragear%20kphotoalbum%20kf5-qt5%20FreeBSDQt5.10/

Cheers,
Johannes
Robert Krawitz
2018-07-12 00:40:36 UTC
Permalink
Post by Johannes Zarl-Zierl
Hi Robert,
Post by Robert Krawitz
Has anyone had a chance to play with these some? I'd like to get this
merged; it will really help people IMO.
I've reviewed and merged the rest of the load-performance-stable
branch now. I have to admit that I did not put too much scrutiny on
the OptimizedFileList, though. At this point I think the feature is
ready for a wider audience ;-)
There's also the startup-performance branch (which I just spotted a
very minor bug that I'm fixing in the MD5 stuff).
Post by Johannes Zarl-Zierl
For the record, two minor issues remain that need fixing before the
next release: (1) there's an unused member variable creating a
warning message
Where's the warning? I don't see it in the log.
Post by Johannes Zarl-Zierl
(2) the implemenation of OptimizedFileList should be made less linux-specific
Yes, statvfs would be a better option here. Unfortunately, statfs is
much less standardized than stat.
Post by Johannes Zarl-Zierl
I'll fix (1) some time this week, but with (2) I'll probably need some time to get a FreeBSD VM set up (I don't want to think of possible Windows compilation for now).
https://build.kde.org/view/Extragear/job/Extragear%20kphotoalbum%20kf5-qt5%20FreeBSDQt5.10/
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Johannes Zarl-Zierl
2018-07-12 10:29:47 UTC
Permalink
Post by Robert Krawitz
There's also the startup-performance branch (which I just spotted a
very minor bug that I'm fixing in the MD5 stuff).
Yes, I'm aware - I'll get to it asap (and then there's two other patchsets,
too: Samuel Kay has a new HTML export, and Andreas Neustifter had an
improvement to video-thumbnail creation IIRC).
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
For the record, two minor issues remain that need fixing before the
next release: (1) there's an unused member variable creating a
warning message
Where's the warning? I don't see it in the log.
Clang 6.0.1 gives:
DB/ImageScout.cpp:74:9: warning: private field 'm_index' is not used [-
Wunused-private-field]
int m_index;
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
(2) the implemenation of OptimizedFileList should be made less linux-specific
Yes, statvfs would be a better option here. Unfortunately, statfs is
much less standardized than stat.
It seems like you know your C library functions and syscalls better than me.
Do you have time to improve cross-platform compatibility here?
As far as I'm concerned, Linux and (Free)BSD should both be supported equally,
if possible. Having a fallback that's possibly slower, but platform-agnostic
is also great.(*)


Cheers,
Johannes

(*) Regarding other platforms: Many(?) KDE applications also support Windows,
but I don't have a build environment for that and as long as nobody pops up
and wants to make a Windows port happen, I'm not investing my limited time
into this. (I'll accept patches, though) I've also heard there's some people
building for MacOs - the same rationale applies here.
Robert Krawitz
2018-07-12 12:10:21 UTC
Permalink
Post by Robert Krawitz
There's also the startup-performance branch (which I just spotted a
very minor bug that I'm fixing in the MD5 stuff).
Yes, I'm aware - I'll get to it asap (and then there's two other patchsets, too: Samuel Kay has a new HTML export, and Andreas Neustifter had an improvement to video-thumbnail creation IIRC).
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
For the record, two minor issues remain that need fixing before the
next release: (1) there's an unused member variable creating a
warning message
Where's the warning? I don't see it in the log.
DB/ImageScout.cpp:74:9: warning: private field 'm_index' is not used [-
Wunused-private-field]
int m_index;
OK.
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
(2) the implemenation of OptimizedFileList should be made less linux-specific
Yes, statvfs would be a better option here. Unfortunately, statfs is
much less standardized than stat.
It seems like you know your C library functions and syscalls better than me. Do you have time to improve cross-platform compatibility here?
As far as I'm concerned, Linux and (Free)BSD should both be supported equally, if possible. Having a fallback that's possibly slower, but platform-agnostic is also great.(*)
This shouldn't be slower. Given what it does, if it were
significantly slower I'd prefer to have it conditioned.
(*) Regarding other platforms: Many(?) KDE applications also support Windows, but I don't have a build environment for that and as long as nobody pops up and wants to make a Windows port happen, I'm not investing my limited time into this. (I'll accept patches, though) I've also heard there's some people building for MacOs - the same rationale applies here.
I don't know Windows myself. That may very well have to be different.
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
s***@401kay.fr
2018-07-12 19:07:44 UTC
Permalink
I wasn't aware that my patch was accepted (and maybe it isn't)...
I was planning to rework the patches (not the code for now) but some other projects take all my time 😞

Regards
Post by Johannes Zarl-Zierl
Post by Robert Krawitz
There's also the startup-performance branch (which I just spotted a
very minor bug that I'm fixing in the MD5 stuff).
Yes, I'm aware - I'll get to it asap (and then there's two other patchsets,
too: Samuel Kay has a new HTML export, and Andreas Neustifter had an
improvement to video-thumbnail creation IIRC).
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
For the record, two minor issues remain that need fixing before the
next release: (1) there's an unused member variable creating a
warning message
Where's the warning? I don't see it in the log.
DB/ImageScout.cpp:74:9: warning: private field 'm_index' is not used [-
Wunused-private-field]
int m_index;
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
(2) the implemenation of OptimizedFileList should be made less linux-specific
Yes, statvfs would be a better option here. Unfortunately, statfs is
much less standardized than stat.
It seems like you know your C library functions and syscalls better than me.
Do you have time to improve cross-platform compatibility here?
As far as I'm concerned, Linux and (Free)BSD should both be supported equally,
if possible. Having a fallback that's possibly slower, but platform-agnostic
is also great.(*)
Cheers,
Johannes
(*) Regarding other platforms: Many(?) KDE applications also support Windows,
but I don't have a build environment for that and as long as nobody pops up
and wants to make a Windows port happen, I'm not investing my limited time
into this. (I'll accept patches, though) I've also heard there's some people
building for MacOs - the same rationale applies here.
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Johannes Zarl-Zierl
2018-07-12 19:56:23 UTC
Permalink
Post by s***@401kay.fr
I wasn't aware that my patch was accepted (and maybe it isn't)...
I was planning to rework the patches (not the code for now) but some other
projects take all my time 😞
There are still some issues with the patches (and of course having small
patches that add up to an easy to follow "story" would make things easier for
me/the reviewer), but I plan on incorporating the changes eventually.

I can totally relate to your woes regarding the available time ;-)

Cheers,
Johannes

Loading...