BrushToRGBArray does not support async mode

[ilbarbax]

As far as I understand the BrushToRGBArray does not support Async mode.
Actually on my application I start a loader animation to show the progress, but the during BrushToRGBArray it hang to zero for different seconds giving the impression that the program freeze while on the subsequent instructions the loader animation run as espected.
Having an async mode I presume it wouldbe possible to handle the loding animation also during BrushToRGBArray.
Or there is an alternative way?

Thanks

[airsoftsoftwair]

I don't understand this question. What do you mean by "async mode"? Are you playing an anim in async mode? But what does it have to do with BrushToRGBArray() then? Please post an MCVE.

[jPV]

I think he means that BrushToRGBArray() is a heavy operation that can take time with lower end systems and large pictures, so he's wanting an "async" option for it to do something else while it's converting. In a similar way that DownloadFile() has the async option... or maybe just setting a callback function would be enough.

Some (graphical) conversions do take time on lower end systems indeed, and I've noticed that especially with 68k systems that seem to "hang" with heavier operations, sometimes I don't even bother to wait if the machine has actually crashed or just doing the processing. In the ideal situation we would have a way to set a callback function or async mode generally with all data processing functions to let users see the progress and possibly to cancel the action, but I don't know if that would be possible in theory or would it make a hit on speed otherwise...

[ilbarbax]

Exactely as explaining jpv

[airsoftsoftwair]

Ah, ok, now I think you can easily implement this yourself. Just convert the brush row-by-row to an RGB array. Then you can easily do other things while the brush is being converted.

Concerning the issue with the locked mouse pointer: I think this only happens with Picasso96 which has the habit of locking the mouse pointer whenever a program locks a bitmap. I've never really liked this behaviour either because it makes apps appear sluggish but I'm afraid there's nothing I can do about this. What you can do, however, is tell Hollywood to not use system bitmaps at all. This can be done by passing the USEWPA argument to Hollywood. Then Hollywood won't use any system bitmaps and no mouse pointer lockups should occur. Drawing might be a bit slower when using USEWPA but it shouldn't really make that much of a difference.

[ilbarbax]

Sorry Andreas, but as far as I understand the BrushToRGBArray is a monolithic function that copies the whole block of data at once. How can I retrieve the data row by row?.
My actual problem is on the fact that the BrushToRGBArray takes a while to take the data of a large picture and the system seems to hang. Of course when I have the whole table of data I can do what I want.

[airsoftsoftwair]

Sorry Andreas, but as far as I understand the BrushToRGBArray is a monolithic function that copies the whole block of data at once. How can I retrieve the data row by row?.

Use a temporary brush whose height is 1 pixel and copy the graphics row-by-row to this brush using SelectBrush() and then BrushToRGBArray(). Of course this will be slower than a single BrushToRGBArray() call but it will allow your app to stay responsive.

[jPV]

Use a temporary brush whose height is 1 pixel and copy the graphics row-by-row to this brush using SelectBrush() and then BrushToRGBArray(). Of course this will be slower than a single BrushToRGBArray() call but it will allow your app to stay responsive.

This of course works for this certain function and functions that deal each pixel individually, but a generic built-in solution in Hollywood would be faster and work with effects that you can't deal row-by-row, like BlurBrush() etc..

[airsoftsoftwair]

This of course works for this certain function and functions that deal each pixel individually, but a generic built-in solution in Hollywood would be faster and work with effects that you can't deal row-by-row, like BlurBrush() etc..

I agree it would be nice to have but it's a lot of work because there are many image processing functions and to make things worse each image processing function exists in 4 flavours: For 8 bit, 16 bit, 24 bit and 32 bit pixels and sometimes even for 1-bit masks. Adapting all these to support passing control back and forth to the script is a lot of work and such a feature benefits only few users probably.