Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Splash screens == sloth

asserttrue.blogspot.com

Post reply on HN
Print view View original

221–230 of 246 posts

Re: Splash screens == sloth

#221

Post by cageface »

JS_startup wrote: post #25

I don't understand what he's angry about. Photoshop, Microsoft Office, OpenOffice, these are all enormously complicated programs that require resources to load. That doesn't make them bloatware and it doesn't make the programmers lazy. His proposed solution sucks too. Show the UI while it's loading so the user can impotently click around waiting for the program to "turn on". Windows does this when it boots up and it…

Personally I don't care how long it takes an app to start provided it stays running once it does start. If I'm doing non-trivial work in an app the boot time is negligible compared to the time I spend working in that app.

Given the tremendous engineering challenges apps of these size pose the last place I'd like to see developers spend their precious time is on this.

Re: Splash screens == sloth

#222

Post by jiggy2011 »

keypusher wrote: post #213
pak wrote: post #205

Earlier quoted context omitted.

Surprisingly, NTFS does allow for transactions [1] and this feature is implemented since Vista, while as far as I know, HFS+ on Macs has no comparable feature. Therefore what you say may in fact be true. I'm curious if cutting the power on a Mac while it's moving files into place will break a software update, or if the whole package receipt mechanism prevents that from occurring. [1] http://en.wikipedia.org/wiki/Tran…

I'm not sure even transactional NTFS would protect you in this case. From the wiki link: Transactional NTFS is implemented on top of the Kernel Transaction Manager (KTM), which is a Windows kernel component. Because this is implemented on top of the kernel itself, if you have brought down the kernel in order to update files within said kernel, you likely are not going to be able to leverage the transactional rollback…

I was thinking more of having a transactional system within the update software itself independent of anything on the filesystem.

Something like this:

1. Download all compressed archives that are required for the update from the update website and unzip somewhere.

2. Check the package manifest and figure out which files need to be changed/added/deleted.

3. Write a flag somewhere on the boot drive that says the update process has begun and which files will be altered.

4. Make copies of all the files which will be changed.

5. Work through the update process by modifying or overwriting the copied files with the contents of the update archives.

6. Temporarily suspend the scheduler so the update process is the only thing running and release locks on all of the files which will be changed.

7. Work through every file that needs to be changed and link the filesystem reference from the old version to the new version whilst keeping a copy of the old version.

8. At every stage in 7 mark in a log which references have been updated.

9. Mark a flag to indicate that the update process has been completed, either resume the scheduler and re-instate locks or force a restart of the OS if necessary.

When the system next starts up as part of the bootup process it can check if both the transaction start and finish flags are set. If the start flag is set but not the finish flag then it knows that an update failed so it can roll back by re-linking to the old versions of every file (reading the logs to know which files to re-link) and setting the start flag back to 0 so it can try again.

If the update was successful then it can delete the old files if the disk space is needed or keep them around in case there is an issue later which required a restore.

In regards the kernel example, my Linux install actually keeps old versions of the kernel on the system so that if a kernel update breaks something for whatever reason it is still possible to boot the system from the previous kernel. I imagine Windows and OSX do something like this , although possibly more transparently.

Note: This is what I could think of off the top of my head, I'm sure it's not a perfect way of doing it but it demonstrates the idea.

Re: Splash screens == sloth

#223

Post by cageface »

systemtrigger wrote: post #218
cageface wrote: post #212

Earlier quoted context omitted.

Adobe stuff is bloatware and sucks. No, it's just vastly more complicated than most of the cut-down alternatives because it has to meet the needs of pro designers. Maybe there's some accumulated cruft there but I can guarantee you that Pixelmator, for example, would be similarly large if it had to support all the same use cases.

Yes though I suspect Photoshop's load time could be significantly reduced by limiting the features available at load time. If the method code for the 223rd most popular effect is loaded into memory prior to the user being able to do anything , Adobe is doing it wrong.

Maybe so, but that kind of dependent loading might also significantly complicate the code. I have no idea how Photoshop actually handles this but it's about as close as software gets to magic already so I'm disinclined to accuse the developers of incompetence or sloth.

Re: Splash screens == sloth

#224

Post by derefr »

LoneWolf wrote: post #194
kzrdude wrote: post #177

Earlier quoted context omitted.

> The spashscreen does 1 thing, it tells the user that the app is loading and you don't need to click the exe/icon again. This is the wrong way to notify. Let its dock icon bounce on (or similar), instead of obscuring the center of the working area on the computer.

Excuse me but I don't see that being possible in Windows In kde it was mac I have no idea but your solution only works in some places.

Then that is a problem with the GUI, not a problem with the program. Don't settle for what's possible; change what's possible.

Re: Splash screens == sloth

#225

Post by davedx »

alex_c wrote: post #154
davedx wrote: post #136

Earlier quoted context omitted.

Why should users have to pay extra?? The new version of Basecamp (by the guys who invented Rails) focused on speed, because speed = $$$. The question is, why would you throw away your userbase because your app is so slow to load, it's cutting into their productivity? There is a very large gap between 'instantly responsive applications' and Photoshop.

Someone has to pay. Whether it's a higher price for users, less time spent on other features, or lower profits for the company, the effort has to come from somewhere. I don't disagree that responsiveness and user experience are important, but Basecamp is a webapp. Responsiveness for the most common tasks is a higher priority than the one-time cost at start-up. I'm not sure anyone is "throwing away their userbase"...…

I don't understand why everyone thinks the fact Basecamp is a webapp is important.

As you say, responsiveness and user experience are important, and 37 Signals decided it was worth investing a significant amount in. Adobe have decided, over the years, that it is not.

Re: Splash screens == sloth

#226

Post by davedx »

JS_startup wrote: post #25

I don't understand what he's angry about. Photoshop, Microsoft Office, OpenOffice, these are all enormously complicated programs that require resources to load. That doesn't make them bloatware and it doesn't make the programmers lazy. His proposed solution sucks too. Show the UI while it's loading so the user can impotently click around waiting for the program to "turn on". Windows does this when it boots up and it…

Loading times like that ARE UX. Wow. What do you think he's writing about? His Experience as a User.

Re: Splash screens == sloth

#227

Post by Nick_C »

jiggy2011 wrote: post #222
keypusher wrote: post #213

Earlier quoted context omitted.

I'm not sure even transactional NTFS would protect you in this case. From the wiki link: Transactional NTFS is implemented on top of the Kernel Transaction Manager (KTM), which is a Windows kernel component. Because this is implemented on top of the kernel itself, if you have brought down the kernel in order to update files within said kernel, you likely are not going to be able to leverage the transactional rollback…

I was thinking more of having a transactional system within the update software itself independent of anything on the filesystem. Something like this: 1. Download all compressed archives that are required for the update from the update website and unzip somewhere. 2. Check the package manifest and figure out which files need to be changed/added/deleted. 3. Write a flag somewhere on the boot drive that says the update…

I don't know if it follows those exact steps, but in the last few months I had several times a machine crash (flaky power supply) in the middle of various Windows Updates and it always recovered pretty well. It looked to this outsider like there was some sort of journalling going on.

Re: Splash screens == sloth

#228

Post by jiggy2011 »

jarrett wrote: post #118

The computers I use now are far more capable than the ones I used in 2005, in terms of CPU, RAM, disk space, GPU, and anything else that should affect an app's boot time. Today, Photoshop takes just as long to boot as it did in 2005. Yet the features I use today are almost identical to those I used in 2005, the only exception being the ability to import camera raw images. (And I'm sure that the binaries for importing…

I imagine load time hasn't improved so much because that's not really what they are optimising for.

You could of course still run an old version of Photoshop on a modern PC if startup time is really that important to you.

I think it would be interesting to compare performance of Photoshop CS5 with Photoshop 6 (the first version I used) on a modern PC.

I would expect of course that PS6 would start up almost instantly whereas CS5 would take a few seconds. However it would be interesting to also take a relatively large image file of the sort of size that a graphics designer might actually work with (let's say 500MB or so) and apply a bunch of the same filters across the whole image (in such a way as to produce an identical result) on the same computer and time them both.

My guess would be that CS5 would be significantly faster which may be partly due to optimisations made at load time. Not sure if anybody has actually measured something like this though?

Re: Splash screens == sloth

#229

Post by jiggy2011 »

cageface wrote: post #212
Maro wrote: post #11

This weekend the 3G mysteriously stopped working on my iPhone, so after months of use, I rebooted it. Rebooting the iPhone takes 1+ minute, and there _is_ a kind of splash screen shown during that time. The reason it appears instantenous during normal use is that it doesn't actually boot or load, it just turns the display back on. Also, many iOS apps actually have splash screens, you just don't see them very often as…

Adobe stuff is bloatware and sucks. No, it's just vastly more complicated than most of the cut-down alternatives because it has to meet the needs of pro designers. Maybe there's some accumulated cruft there but I can guarantee you that Pixelmator, for example, would be similarly large if it had to support all the same use cases.

Yes, part of the problem that Photoshop has is that it is seen as the "go-to" tool for doing any kind of graphics work at all.

Many people install pirate Photoshop to resize and put a few filters on their photos and complain that is it too slow and complicated when really they could have achieved the same result from either a freeware program or a significantly cheaper commercial one.

Re: Splash screens == sloth

#230

Post by jiggy2011 »

gavanwoolery wrote: post #98

Photoshop really is not that complex - you could write a photoshop clone that would load in under a second, easily. But it loads all sorts of stuff you do not need up front - many fonts, textures, drivers for scanners, cameras, and so forth. I think the real problem is that Adobe seems to keep patching an already bloated code base - I think if they started fresh they could redesign it more efficiently...just my humbl…

I think it would be difficult to write a photoshop clone that loads in under a second and provides the same level of performance when dealing with advanced filters on huge images with hundreds of layers.

Anyway I doubt that all of that stuff is loaded at startup anyway.

Post reply on HN