LoadBrush *feature request*...

[Tuxedo]

Hi Andreas!
Sorry to ask you again but I dont remember and dont found anything searching in hte forum from old discussions...

Regarding the old request to have image load in multithreading or similar way you ave stated that atm that wasnt pocssible and that I remember.
The thing I dont remember was if I ever ask you to have a function in LoadBrush to have similar behaviours of the AsyncDraw frame or the PlayMusic command similar...

Or simply get a LoadBrush command with an "async" parameter...

I need that, as you knowm, to add background image loading in LoView...
I think LoView was now a quite complete image viewer but without the backround function was really problematic to use it with big pictures as you may imagine...

I dunno how difficult can be that but plz take it in consideration.

[airsoftsoftwair]

Sorry, that's far too much work for too little gain. There are more important things to spend time on

[djrikki]

Well speed-wise not a lot you can do, but if you want to avoid interface stall (so user could scroll foreinstance or browse to the parent directory without waiting) you could load the images in the background using SetInterval(). Of course its a bit more complex than that - at present I don't even use anything remotely as sophisticated as that in Jack - but now I know more about SetInterval() I can imagine the possibilities it could bring to Jack's full-screen image viewer and the solution you are looking for.

SetInterval() has low system latency, look at the clock in Jack - its using SetInterval() to grab the system time every second whilst the rest of the interface remains unblocked.

So you could parse through the drawer loading brushes, populating an array - image res, width, height, camera mode, shutter speed etc... Your screen redraw routine simply draws what has been loaded at that point in time. When all available images have been loaded the Interval is cleared.

[Tuxedo]

Well speed-wise not a lot you can do, but if you want to avoid interface stall (so user could scroll foreinstance or browse to the parent directory without waiting) you could load the images in the background using SetInterval(). Of course its a bit more complex than that - at present I don't even use anything remotely as sophisticated as that in Jack - but now I know more about SetInterval() I can imagine the possibilities it could bring to Jack's full-screen image viewer and the solution you are looking for.

SetInterval() has low system latency, look at the clock in Jack - its using SetInterval() to grab the system time every second whilst the rest of the interface remains unblocked.

So you could parse through the drawer loading brushes, populating an array - image res, width, height, camera mode, shutter speed etc... Your screen redraw routine simply draws what has been loaded at that point in time. When all available images have been loaded the Interval is cleared.

mmm...
I think you cant...dont tryed atm but...when you call LoadBrush it will lock whole Hollywood, no matter if it was in mai program trunk otr in a SetInterval...your clock dont lock it simply why its too poor cpu intensive...


@Andreas

Well life was made for priorities...however "multithreadinbg" LoadBrush will help also on big projects to be more confortable and well working not only on my program...
Only hope that you will solve that one, not so far, day...

[jalih]

I think you cant...dont tryed atm but...when you call LoadBrush it will lock whole Hollywood, no matter if it was in mai program trunk otr in a SetInterval...your clock dont lock it simply why its too poor cpu intensive...

I think djrikki ment that istead of just loading all the brushes in one long loop, you could do your own "housekeeping" and use interval function to load smaller amounts of brushes at a time.

[Tuxedo]

I load images only when needed..but the problem was that with big images (10Mpx and more) load time can be also of some seconds and that was really annoiing...

[djrikki]

Thats the crux of the problem, Hollywood is not really intended for loading huge high resolution images. The speed you are experiencing will always be below-par no matter what hardware and software configuration you try and open these kinds of images on.

[Tuxedo]

Thats the crux of the problem, Hollywood is not really intended for loading huge high resolution images. The speed you are experiencing will always be below-par no matter what hardware and software configuration you try and open these kinds of images on.

For sure!
However if Hollywood will improve that was only a good thing

[Tuxedo]

@Andreas

last info about that topic...
I noticed that displaying same big picture(http://www.v12-gt.com/var/v12gt/storage ... -jante.jpg) with LoView and with MultiView give me different time(I measured MultiView time roughly)...
MultiView seems faster about 10/15% against LoView(and so Hollywood) any reason on why?

Thank you!

[airsoftsoftwair]

Maybe Multiview loads images into video RAM. Hollywood normally prefers fast RAM.