Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Hourglass in long operations (project loading)

<< < (4/8) > >>

takeshimiya:

--- Quote from: iw2nhl on July 27, 2006, 01:37:15 am ---What I mean is that now the code is slow and takes a long time.
When the new code will be ready, we will speak about that way of working.
Now we have another code, a slow code.

--- End quote ---
I agree with that philosophy. It's called a quick & dirty fix.


--- Quote ---Its usage is popular among hackers, who use it to describe a crude solution or programming implementation that is imperfect, inelegant, or otherwise inadequate, but which solves or masks the problem at hand, and is generally faster and easier to put in place than a proper solution.

Quick-and-dirty solutions often attend to a specific instance of a problem rather than fixing the cause of the more general problem. As such, they are sometimes used to keep an item of software or hardware working temporarily until a proper fix can be made.
--- End quote ---

And in this case, it's just a matter of philosophy.

thomas:

--- Quote from: Takeshi Miya on July 27, 2006, 07:15:36 am ---I agree with that philosophy. It's called a quick & dirty fix.
--- End quote ---
No Takeshi, it's called a no-fix.

A real quick and dirty fix would be to insert Freeze() and Thaw() into MainFrame::OnDropFiles. This indeed fixes something, even if not in a pretty way. It removes flicker and speeds up loading DnD files quite noticeably (on a rough estimate by a factor of 3 or 4).

Another quick and dirty fix is to disable plugin notifications for each individual opened file while walking through the list of dropped files, but that would change SDK behaviour.

killerbot:
It does not solve anything. Absolutely. So I do NOT want to discuss that. Just 'feedback' to the user.

A few weeks ago, I installed CB on a colleagues pc, and opened there a project. CB loaded the project and had it's little share of unresponsiveness (clicking somewhere sometimes turn the menu bar white). I did not say a word, well i said, it takes sometime but so does MSVC ;-)

The fact the hourglass is there looks to me as a good compromise, when people see the hourglass the get a first impression somethings happening (but to be honest I have seen programs cras/freeze while looking at their hourglass ;-) ) and as long as the cursor does not have it's normal looks it prevents most of the users to click anywhere else.
My "personal opinion" : for that purpose I like it.

And even when the loading is optimized in future, you always have people with very big projects/workspaces and even then it might serve the same purpose.

thomas:
You see, I am not against showing that hourglass cursor. What I am against is to show a hourglass cursor instead of actually digging for the root of the evil.

For example, in the case of drag and drop, a simple Freeze() and Thaw() works wonders, and if you process a paint event just before freezing the window, then it is not even visually unpleasing.
This is still not pretty, but it successfully works around some of the problem. It actually causes 20 files to be loaded almost instantly when in the cache (and in well under a second otherwise), as the massive GUI overdraw is not done any more.
Add the busy cursor to that? I shan't be bothered, it will only be visible for a fraction of a second anyway...

Of course it would be better to fix the problem in another place, since even without overdraw, we are having unnecessary overhead. For example, when opening 25 files, we rebuild the "Recent Files" menu 25 times from scratch, which fires around 75 update UI events, which are processed by several handlers each. Rebuilding the menu only once at the end of the batch would be the right thing to do. However, this is of course a lot more work than calling Freeze() and Thaw().
There's more to it than just that, but that's one example.

kidmosey:
I can see the merit in wanting to optimize the loading procedures, and I completely agree that locking the user out is not a very good option; but for every PC that can load 20 files in under a second, there are likely 100 PC's that will take several seconds to load the same files.  Optimizations, IMO, only allow the user to do more things to get the same slow-down.  I am running about 8 different apps, now (encoding, compiling, etc...), because that is what my PC can handle while still having tolerable performance.

I do think there should be some indicator that the application is doing something, besides just a frozen workspace icon in the manager pane or a cursor that lets you do nothing.  Maybe insert a small progress bar at the base of the pane to let the user know there IS something happening, and to also notify them when the loading is completed.

This will also let you know if the app has frozen, because the progress indicator will not change for a while.  True, this is yet another feature that could slow down the loading, and it may be difficult to implement, but it seems like a better solution than the antiquated hourglass.

Navigation

[0] Message Index

[#] Next page

[*] Previous page