I have an 6MB SVG image in my SVG folder and it took over half an hour to show the preview on my P800! It is even slow, if I browse some bigger PNGs. If you worry about not being up to date you can compare the timestamp in the thumbnail with the file date. And no, I don't think that thumbnails are garbage, as long as all programs use the same.
Well, 6Mb is not what I would call typical. Half an hour sounds like a lot. How long does it take to actually open that file?
On a 450MHz Windows machine that I tested, it works quite acceptably for SVG files of average size and complexity (up to several hundred Kbytes). I'm not saying using stored previews is not an option; I'm just saying that the current code works quite acceptably for the average user, so implementing an alternative is not a priority (though of course I would not object if someone develops and commits it).
I'm just speaking about the preview area. It has the "Preview" title,
Which is rather redundant IMHO, especially being so button-looking - is it actually clickable? what does it do? why does it have a keyboard accelerator?
What we actually need is a checkbox or an expander triangle to turn the preview on or off.
some space around the image
Which is confusing - I want the preview to match the actual look, without having to guess if this margin an actual part of the file or not
shows the file size
Which is good, but properly belongs in the file list as a separate sort-able column, not in the preview (by the way, Bob, can we add the filesize column to the list?)
and displays a folder icon, if you are an a folder an not on an image.
It might make sense to borrow that one.
On Sun, 2004-08-08 at 17:22, bulia byak wrote:
I have an 6MB SVG image in my SVG folder and it took over half an hour to show the preview on my P800! It is even slow, if I browse some bigger PNGs. If you worry about not being up to date you can compare the timestamp in the thumbnail with the file date. And no, I don't think that thumbnails are garbage, as long as all programs use the same.
Well, 6Mb is not what I would call typical.
Not typical, but it happens. And woe be unto the user that unknowlingly or accidentally selects such a file...
Actually I've seen much smaller files that, properly constructed, can bring Inkscape to its knees (e.g. the Chinese Checkers SVG that I believe is attached to one of our closed <use>/performance bugs).
This would not be as big an issue if we could load files asynchronously, though memory exhaustion is still an issue.
Actually an incremental loader that could be run asynchronously (from the idle loop) shouldn't prove too hard to implement.
We'd just need to create a stub SPReprDoc, create an SPDocument from that, and leave an idle handler running using libxml's event-based API to read XML tokens and make additions to the SPRepr tree as events arrive until the file is completely read.
What we actually need is a checkbox or an expander triangle to turn the preview on or off.
That makes sense, I think. Default to expanded the first time though.
some space around the image
Which is confusing - I want the preview to match the actual look, without having to guess if this margin an actual part of the file or not
Some padding around the image border looks better IMO, but I think there does need to be a border rectangle so the actual image dimensions/"margins" are apparent.
shows the file size
Which is good, but properly belongs in the file list as a separate sort-able column, not in the preview (by the way, Bob, can we add the filesize column to the list?)
Hmm, I like it in the preview, IMO. Maybe in addition to the file list, but still...
and displays a folder icon, if you are an a folder an not on an image.
It might make sense to borrow that one.
Yes, I think that's somewhat important for consistency.
-mental
bulia byak wrote:
I have an 6MB SVG image in my SVG folder and it took over half an hour to show the preview on my P800! It is even slow, if I browse some bigger PNGs. If you worry about not being up to date you can compare the timestamp in the thumbnail with the file date. And no, I don't think that thumbnails are garbage, as long as all programs use the same.
Well, 6Mb is not what I would call typical. Half an hour sounds like a lot. How long does it take to actually open that file?
AHA!!!!!
I have the solution!!!!
XMP thumbnail metadata!!!
If that 6MB file was generated with an Adobe tool, it's in there. If not, we can get Inkscape to stick one in for a one-time hit.
I was thinking this (the open dialog) was a very good place to use that metadata, as it seems like a lot of the reason for including it in the first place.
On Mon, 2004-08-09 at 02:13, Jon A. Cruz wrote:
If that 6MB file was generated with an Adobe tool, it's in there. If not, we can get Inkscape to stick one in for a one-time hit.
At Inkscape's current level of XML support I wouldn't trust it to do that without potential corruption. There is a lot we need to fix yet...
-mental
MenTaLguY wrote:
On Mon, 2004-08-09 at 02:13, Jon A. Cruz wrote:
If that 6MB file was generated with an Adobe tool, it's in there. If not, we can get Inkscape to stick one in for a one-time hit.
At Inkscape's current level of XML support I wouldn't trust it to do that without potential corruption. There is a lot we need to fix yet...
Neither would I.
I was thinking of mainly just saving thumbnails when Inkscape saves out. Not in inserting to existing files.
1) in dialog: if file is small enough use Inkscape's rendering else if file has XMP chunk. if file has thumbnail use embedded thumbnail
2) Add XMP thumbnail when Inkscape saves.
Do that, then the open dialog will handle anything generated from an Adobe tool, and then Inkscape generated once we add feature 2.
participants (3)
-
bulia byak -
Jon A. Cruz -
MenTaLguY