Hi to all.
I dont know if this are discussed previously, but whats your opinion of a loading/running screen for inkscape?
Regards, Jabier.
Maybe this loading/running screen can have a donate link...
Regards.
El jue, 25-09-2014 a las 11:10 +0200, Jabiertxo Arraiza Cenoz escribió:
Hi to all.
I dont know if this are discussed previously, but whats your opinion of a loading/running screen for inkscape?
Regards, Jabier.
On Thu, 2014-09-25 at 11:10 +0200, Jabiertxo Arraiza Cenoz wrote:
I dont know if this are discussed previously, but whats your opinion of a loading/running screen for inkscape?
This isn't my opinion, but it is the one I remember being talked about before:
"If Inkscape needs a loading screen, then it's failing to load quickly enough and we should spend time on making inkscape faster instead"
Of course the miserated speed of inkscape on anything other than a core2 is a real big problem. But something I don't think that can be tackled until we have paid developers who do nothing but speed improvement bugs.
I'd also put the donate/contribute button in the UI, rather than on something quickly flashing up and falling away.
Martin,
Thanks Martin.
You are ok, but still are machines -mine- slow or sometimes overloaded and launch varius instances of inkscape by impacience -mine- people dont help them ;)
+1 to the GUI donate/contribute button. Another option in help Menu? About page?
Regards, Jabier-
El jue, 25-09-2014 a las 11:01 -0400, Martin Owens escribió:
On Thu, 2014-09-25 at 11:10 +0200, Jabiertxo Arraiza Cenoz wrote:
I dont know if this are discussed previously, but whats your opinion of a loading/running screen for inkscape?
This isn't my opinion, but it is the one I remember being talked about before:
"If Inkscape needs a loading screen, then it's failing to load quickly enough and we should spend time on making inkscape faster instead"
Of course the miserated speed of inkscape on anything other than a core2 is a real big problem. But something I don't think that can be tackled until we have paid developers who do nothing but speed improvement bugs.
I'd also put the donate/contribute button in the UI, rather than on something quickly flashing up and falling away.
Martin,
On 25-9-2014 17:38, Jabiertxo Arraiza Cenoz wrote:
Thanks Martin.
You are ok, but still are machines -mine- slow or sometimes overloaded and launch varius instances of inkscape by impacience -mine- people dont help them ;)
+1 to the GUI donate/contribute button. Another option in help Menu? About page?
-1 to any donate buttons in the UI, anywhere.
Johan
On 25-Sep-2014 08:01, Martin Owens wrote:
This isn't my opinion, but it is the one I remember being talked about before:
"If Inkscape needs a loading screen, then it's failing to load quickly enough and we should spend time on making inkscape faster instead"
That's where I stand too. Much better to put the effort into speeding the start up (which is awfully slow on Windows, about 30 seconds on my dual core Athlon X2 desktop) than to provide the end user with eye candy while the program crawls into being.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 25-9-2014 17:01, Martin Owens wrote:
On Thu, 2014-09-25 at 11:10 +0200, Jabiertxo Arraiza Cenoz wrote:
I dont know if this are discussed previously, but whats your opinion of a loading/running screen for inkscape?
This isn't my opinion, but it is the one I remember being talked about before:
"If Inkscape needs a loading screen, then it's failing to load quickly enough and we should spend time on making inkscape faster instead"
This argument does not make sense to me. It is trivial to make a splash screen that pops up instantly and will only slow down Inkscape's boot time by milliseconds. I do not see how this minor piece of work would detract significantly from other development work. I'd love to see a splash screen.
Of course the miserated speed of inkscape on anything other than a core2 is a real big problem. But something I don't think that can be tackled until we have paid developers who do nothing but speed improvement bugs.
I do not think we need paid developers to look into this. We just need *any* developer to work on this. We don't have to render icons from SVG upon startup, load all the systems fonts, etc. Just put in a few debug messages and see for yourself where Inkscape is spending a lot of time on boot. I'm sure others here can add to this list of straightforward tasks to speed up boot time, if anybody is interested. These areas could be worked on by any dev, not only paid devs specifically I feel.
-Johan
On Tue, 2014-09-30 at 01:40 +0200, Johan Engelen wrote:
These areas could be worked on by any dev, not only paid devs specifically I feel.
Sure. that goes for any task. But devs will work on what interests them, or what they're being paid for. Paying them just allows the project to demand certain things that are good for the project and not just interesting.
Martin,
On Mon, Sep 29, 2014 at 4:40 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 25-9-2014 17:01, Martin Owens wrote:
Of course the miserated speed of inkscape on anything other than a core2 is a real big problem. But something I don't think that can be tackled until we have paid developers who do nothing but speed improvement bugs.
I do not think we need paid developers to look into this. We just need *any* developer to work on this. We don't have to render icons from SVG upon startup, load all the systems fonts, etc.
Well, I'd be interested to know what experimental starting up on a lower end machine is like. It may not be a magical and huge difference, but Liam made some great improvements with launch speed there.
As for the icons, if I recall correctly, they get cached on first launch and only get re-rendered if the source file gets modified.
Cheers, Josh
On 30-9-2014 2:48, Josh Andler wrote:
On Mon, Sep 29, 2014 at 4:40 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 25-9-2014 17:01, Martin Owens wrote:
Of course the miserated speed of inkscape on anything other than a core2 is a real big problem. But something I don't think that can be tackled until we have paid developers who do nothing but speed improvement bugs.
I do not think we need paid developers to look into this. We just need *any* developer to work on this. We don't have to render icons from SVG upon startup, load all the systems fonts, etc.
Well, I'd be interested to know what experimental starting up on a lower end machine is like. It may not be a magical and huge difference, but Liam made some great improvements with launch speed there.
Tbh, on my core-i7, the startup time is long enough to warrant a splash screen. Plus, what is the downside of a splash screen? :)
As for the icons, if I recall correctly, they get cached on first launch and only get re-rendered if the source file gets modified.
I count 1044 calls to SPPath::build upon starting trunk (after starting it several times). Perhaps it's not the icons, but something is creating a lot of SVG objects. Otoh, the boottime is dominated by something else, because the majority of time is spent before the calls to SPPath::build are performed; the part /with/ calls to SPPath::build appears fast on my machine.
-Johan
On Tue, Sep 30, 2014 at 2:23 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
Tbh, on my core-i7, the startup time is long enough to warrant a splash screen. Plus, what is the downside of a splash screen? :)
On my 3 year old laptop i7 it takes ~2.3 seconds to launch experimental vs ~8 seconds for trunk. I'm not completely against a splash screen, but still think it boils down to us not optimizing enough if it's needed. Liam has done a great job improving the situation already which is why I specifically questioned experimental on older/slower equipment.
I do want to say, I know not everyone has new-ish equipment, so if a splash is needed to let users know something is happening, so be it.
Cheers, Josh
On 30-9-2014 23:39, Josh Andler wrote:
On Tue, Sep 30, 2014 at 2:23 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
Tbh, on my core-i7, the startup time is long enough to warrant a splash screen. Plus, what is the downside of a splash screen? :)
On my 3 year old laptop i7 it takes ~2.3 seconds to launch experimental vs ~8 seconds for trunk. I'm not completely against a splash screen, but still think it boils down to us not optimizing enough if it's needed. Liam has done a great job improving the situation already which is why I specifically questioned experimental on older/slower equipment.
Indeed experimental is quite a bit faster. But when opening a complicated PDF with Inkscape, it can take a minute or so and in that case a splash screen would really be nice.
For me, a splash screen makes sense for start times above a second or so.
-Johan
On Wed, 2014-10-01 at 00:39 +0200, Johan Engelen wrote:
For me, a splash screen makes sense for start times above a second or so.
Actually two human ticks, so about 400 to 600ms is when people start to question if their action actually did anything and may prompt clicking on the icon again.
But part of that is just every operating system in existence not telling the user that something is happening with an application they've asked to load.
Maybe a build flag for a splash screen would be nice.
Martin,
I don't like splash screen for the purpose of a splash screen (like ESET do) but I feel your pain if you have a slow computer and you don't know if Inkscape is actually starting up or not. The best solution I've seen to this problem is the one GIMP uses. They have a splash screen _with_ a loading bar for all modules and settings that are loaded during start up.
Just as Martin Owens says, something needs to be shown to the user in about 500ms otherwise another instance is started with another double-click on the icon.
Martin, what do you mean with a "build flag for a splash screen"? a loading bar just like GIMP?
I would go for the progress bar: at least someone will be forced to take a deep look at the whole startup process and appropriately weight each step. I'm pretty sure that some anomalies will eventually be spotted. This would also let people report the percentages where the bar hesitates more, thus giving hints on where the most critical parts are (maybe with differences between systems): a nice debug tool.
-- View this message in context: http://inkscape.13.x6.nabble.com/Running-Screen-tp4971605p4971641.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Tue, Sep 30, 2014, at 03:39 PM, Johan Engelen wrote:
Indeed experimental is quite a bit faster. But when opening a complicated PDF with Inkscape, it can take a minute or so and in that case a splash screen would really be nice.
For me, a splash screen makes sense for start times above a second or so.
Good scenario.
One alternative for this use case is to have the base UI come up quickly and then have a separate loading phase where a progress bar might be included.
However, I definitely think that we need to keep this specific workflow captured and listed along with other use cases that might pertain to app launching.
Tue, 30 Sep 2014 01:40:38 +0200 Johan Engelen <jbc.engelen@...2592...> kirjoitti:
"If Inkscape needs a loading screen, then it's failing to load quickly enough and we should spend time on making inkscape faster instead"
This argument does not make sense to me. It is trivial to make a splash screen that pops up instantly and will only slow down Inkscape's boot time by milliseconds. I do not see how this minor piece of work would detract significantly from other development work. I'd love to see a splash screen.
I guess you're missing the point of that argument. It's not that a splash screen would be a major effort or that it would slow down Inkscape start.
The thing is: a splash screen is a crutch. It's sure nice to have if you really need one, but it's much better to not need it in the first place.
Given the choice what to see within 500 ms of click on Inkscape icon, I'd really rather see the main Inkscape UI than a splash screen.
On 3-10-2014 18:30, Niko Kiirala wrote:
Tue, 30 Sep 2014 01:40:38 +0200 Johan Engelen <jbc.engelen@...2592...> kirjoitti:
"If Inkscape needs a loading screen, then it's failing to load quickly enough and we should spend time on making inkscape faster instead"
This argument does not make sense to me. It is trivial to make a splash screen that pops up instantly and will only slow down Inkscape's boot time by milliseconds. I do not see how this minor piece of work would detract significantly from other development work. I'd love to see a splash screen.
I guess you're missing the point of that argument. It's not that a splash screen would be a major effort or that it would slow down Inkscape start.
The thing is: a splash screen is a crutch. It's sure nice to have if you really need one, but it's much better to not need it in the first place.
From your explanation, I am not missing the point of the argument. It's just that it fails to provide a solution for the problem at hand.
The problem is that Inkscape starts too slowly (for some people's taste anyway), and that people (me too) start another instance of Inkscape thinking that the first one is not starting. The proposed solution is a splash screen, to tell people to hang in there and wait a little. The "argument" argues that instead, we should make Inkscape faster. Of course we should. Who can disagree with that? But, how do we do that? How to solve the problem? A statement of the form "Inkscape is too X", is not magically solved with an answer of the form "we should make Inkscape not X". Anyone is very welcome to work on making Inkscape start faster. As Josh pointed out, experimental already starts faster than trunk (for me too). Until we get below 500 ms, say, we can have a splash screen. I see no harm in that. As soon as we can show below 1 sec startup time, we kill the splash screen.
Given the choice what to see within 500 ms of click on Inkscape icon, I'd really rather see the main Inkscape UI than a splash screen.
I would rather see a splash screen than a (probably one-minute-unresponsive) main screen. But that is just taste. If you manage to get Inkscape's UI showing within half a second, with a "Loading..." text/progressbar on it, that'd be fine for me too.
-Johan
On 03-Oct-2014 16:05, Johan Engelen wrote:
The problem is that Inkscape starts too slowly (for some people's taste anyway), and that people (me too) start another instance of Inkscape thinking that the first one is not starting. The proposed solution is a splash screen, to tell people to hang in there and wait a little.
Splash screens that consist of little spinning circles and the like are pretty much worthless. They show something is going on, but for all the end user knows it may go on for a very long time. An advancing status bar is a little better, since it describes visually that things are proceeding. Again though, the bar is rarely linear with time, so it might get up to 95% quickly and then take 5% for the last bit. (I cannot count the number of OS installs I have been through where a status bar stops at 99% for a long, frustrating time.) The approach I prefer is probably one most end users would not initially much care for: a small text box that scrolls a small number of lines up with "stage" status messages. Something along these lines (these stages are entirely made up):
00:00.00 Starting 00:00.10 UI initialized 00:00.20 Loading icons 00:01.23 Loading fonts 00:12.46 Loading widgets ... 01:56.32 Started
and it disappears at Started so quickly that nobody should ever be able to read that. The advantage of this is that the user can tell what the current stage is. Then they, or other developers, will complain to the developers that "inkscape is taking 11 seconds to get through 'Loading Widgets'", which tells us where the slow parts are and provides a stimulus to speed those parts up. When all the slow parts have been fixed the user (or installer for the next version) can change the default startup to
inkscape --nosplash
I fear though that in the case of Inkscape this approach might not be feasible because it may well be trying to do several things at once during startup. This is not very helpful:
00:00.00 Starting 01:56.32 UI initialized 01:56.32 Loading icons 01:56.32 Loading fonts 01:56.32 Loading widgets ... 01:56.32 Started
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Splash screens that consist of little spinning circles and the like are pretty much worthless. They show something is going on, but for all the end user knows it may go on for a very long time. An advancing status bar is a little better, since it describes visually that things are proceeding. Again though, the bar is rarely linear with time, so it might get up to 95% quickly and then take 5% for the last bit. (I cannot count the number of OS installs I have been through where a status bar stops at 99% for a long, frustrating time.) The approach I prefer is probably one most end users would not initially much care for: a small text box that scrolls a small number of lines up with "stage" status messages.
I fully agree. Adobe Illustrator uses this approach, beside a launch feedback, the splash screen, with its stage informations, helps to know which part takes the most time to launch. For example, by seeing that fonts take a lot of time to load, you could choose to get rid of some of them in order to speed the software's launch.
T.
mathog wrote
I fear though that in the case of Inkscape this approach might not be feasible because it may well be trying to do several things at once during startup. This is not very helpful:
00:00.00 Starting 01:56.32 UI initialized 01:56.32 Loading icons 01:56.32 Loading fonts 01:56.32 Loading widgets ... 01:56.32 Started
Well, if the startup is multithreaded you can either show a single progress bar made up of the sum of all the single steps, with no possibility to discriminate every single contribute, or show all operations, each with its percentage (or bar) on the side, so you can see which one is the longest lasting. Or a simpler solution could be outputting something like:
00:00.00 Launching... 00:00.15 Starting UI initialization... 00:00.16 Loading fonts... 00:00.16 Loading widgets... 00:00.16 Loading icons... ... 00:43.50 Widgets loaded. 01:21.32 Fonts loaded. 01:56.32 UI initialized. 01:56.32 Launched.
And maybe save everything to a startup.log file using current date and time instead of deltas. Moreover, if this piece of information is stored on a file, a better looking startup window could take its place: some nice icon coloring up like a bar, a slowly fading image, a slideshow, etc. But this would need a bigger effort so maybe better start with a dirtier and quicker solution, for now.
I often find myself opening Process Explorer to check whether Inkscape is starting so I'm in favor of every possible approach that shows something in a human-friendly time interval after the double click. Of course this doesn't mean that I'm happy spending time looking at a startup log or progress bar so all efforts to get rid of them and speed up the process are welcome. IMHO it's a matter of being polite with the user: "You called me: here I am! Now, please, just wait a minute or two and sorry for being so slow...".
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Running-Screen-tp4971605p4971670.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
I have seen programs that use something called a "splash screen" which is an image that is displayed briefly, during the loading of the program. It's displayed, for a few seconds, even if the program loads instantly, without any delay.
For example, my internet security program, ESET, uses a splash screen. And ESET is known for its speed. The splash screen is displayed for maybe 2 or 3 seconds. (Granted the speed it's known for is more related to scanning, but it does open almost instantaneously!)
For a graphics program, I think this would be an awesome feature. The trick would be deciding how long to display it. Not long enough to annoy folks, but not so fast you can't appreciate the image. I would think a very large image would not be appropriate....unless it was quite simple. But say 400 x 500 pixels (or vice versa) would work.
(Maybe there could even be multiple images, with 1 displayed at random, upon opening Inkscape. Maybe the user could populate the file themselves, and/or have the option of using default images. This would make for awesome contests or competitions -- endless possibilities!)
Hhmm...I guess for Inkscape, this would happen whenever a new document is opened....right? All the more reason to have mulitple images available!
Using such a splash screen / running screen doesn't mean you stop working on loading speed; doesn't mean it's compensating for slow loading, just because it's there. It's just a nice bonus feature! If Inkscape opens behind the image, before it goes away, awesome. If not....better than twiddling your fingers! :-)
I think it would at least warrant a new feature request. Of course, I always hesitate before making a new feature request, because it seems sometimes that work on the "bread and butter" part of Inkscape should come first. Or maybe Jabier has some ideas about developing it already???
Thoughts from a loyal Inkscape user :-D
-------------------------------------------------- From: "Jabiertxo Arraiza Cenoz" <jabier.arraiza@...2893...> Sent: Thursday, September 25, 2014 3:10 AM To: "inkscape-devel" inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Running Screen
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.cl...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
El lun, 29-09-2014 a las 16:53 -0600, Brynn escribió:
I think it would at least warrant a new feature request. Of course, I always hesitate before making a new feature request, because it seems sometimes that work on the "bread and butter" part of Inkscape should come first. Or maybe Jabier has some ideas about developing it already???
Hy Brynn. I could take the witness but sure there is better developers to do it.
My idea is: Programaticaly: Show a "bar" and info about happen Design -a bit crazy-: A progress var whith the inkscape logo in full white interpolated to the black/white logo at end -of climate change-
Regards, Jabier.
A quick climate bar/var: http://fc04.deviantart.net/fs70/f/2014/274/f/0/inkscape_climate_by_jabiertxo...
Regards.
El mié, 01-10-2014 a las 22:05 +0200, Jabiertxo Arraiza Cenoz escribió:
El lun, 29-09-2014 a las 16:53 -0600, Brynn escribió:
I think it would at least warrant a new feature request. Of course, I always hesitate before making a new feature request, because it seems sometimes that work on the "bread and butter" part of Inkscape should come first. Or maybe Jabier has some ideas about developing it already???
Hy Brynn. I could take the witness but sure there is better developers to do it.
My idea is: Programaticaly: Show a "bar" and info about happen Design -a bit crazy-: A progress var whith the inkscape logo in full white interpolated to the black/white logo at end -of climate change-
Regards, Jabier.
too fast animation to show -in my browser- here one more slow: http://sta.sh/020z4pjyuoyu
El jue, 02-10-2014 a las 01:06 +0200, Jabiertxo Arraiza Cenoz escribió:
A quick climate bar/var: http://fc04.deviantart.net/fs70/f/2014/274/f/0/inkscape_climate_by_jabiertxo...
Regards.
El mié, 01-10-2014 a las 22:05 +0200, Jabiertxo Arraiza Cenoz escribió:
El lun, 29-09-2014 a las 16:53 -0600, Brynn escribió:
I think it would at least warrant a new feature request. Of course, I always hesitate before making a new feature request, because it seems sometimes that work on the "bread and butter" part of Inkscape should come first. Or maybe Jabier has some ideas about developing it already???
Hy Brynn. I could take the witness but sure there is better developers to do it.
My idea is: Programaticaly: Show a "bar" and info about happen Design -a bit crazy-: A progress var whith the inkscape logo in full white interpolated to the black/white logo at end -of climate change-
Regards, Jabier.
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2014-10-02 at 01:44 +0200, Jabiertxo Arraiza Cenoz wrote:
too fast animation to show -in my browser- here one more slow: http://sta.sh/020z4pjyuoyu
You could always upload to your InkSpace ;-)
http://inkscape.org/en/person/
Martin,
http://inkscape.org/en/gallery/item/776/
El mié, 01-10-2014 a las 21:16 -0400, Martin Owens escribió:
On Thu, 2014-10-02 at 01:44 +0200, Jabiertxo Arraiza Cenoz wrote:
too fast animation to show -in my browser- here one more slow: http://sta.sh/020z4pjyuoyu
You could always upload to your InkSpace ;-)
http://inkscape.org/en/person/
Martin,
On Thu, 2014-10-02 at 12:25 +0200, Jabiertxo Arraiza Cenoz wrote:
Thanks Jabier, this is a great example for animation in svg. Image tags don't work so well for svg animation ATM (in firefox) but I hope this will change. (anyone know of any good tricks in html?)
Martin,
I like that! Except maybe side to side motion would be better?
-------------------------------------------------- From: "Jabiertxo Arraiza Cenoz" <jabier.arraiza@...2893...> Sent: Wednesday, October 01, 2014 5:06 PM To: "Brynn" <brynn@...3133...> Cc: "inkscape-devel" inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Running Screen
Maybe but is like snow. Also we can alert about the climate change here.
El jue, 02-10-2014 a las 19:01 -0600, Brynn escribió:
I like that! Except maybe side to side motion would be better?
From: "Jabiertxo Arraiza Cenoz" <jabier.arraiza@...2893...> Sent: Wednesday, October 01, 2014 5:06 PM To: "Brynn" <brynn@...3133...> Cc: "inkscape-devel" inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Running Screen
participants (11)
-
Brynn -
Christoffer Holmstedt -
Jabiertxo Arraiza Cenoz -
Johan Engelen -
Jon A. Cruz -
Josh Andler -
LucaDC -
Martin Owens -
mathog -
Niko Kiirala -
TozZ