Whit HW colors transform i mean the use of special register of the video card that can be use to change as fast as possible the bitmap colors. Think about your "ReLight" software, you can change the colors parameters (Hue, saturation... and so on) at the speed of light.
If i recall there was special register in vesa mode that automatically draw in grayscale and other features. Don't know if these features still today or have been kept for compatibility reason.
Whit HW colors transform i mean the use of special register of the video card that can be use to change as fast as possible the bitmap colors. Think about your "ReLight" software, you can change the colors parameters (Hue, saturation... and so on) at the speed of light.
Ah, okay. So actual colour transformations. The composited video feature allows you to provide a custom YUV=>RGB matrix when compositing YUV bitmaps, so you can use it to perform custom transformations (e.g., brightness, contrast, hue, saturation). The custom YUV=>RGB matrix feature was included just in case a new YUV standard is invented with slightly different matrix values, but it can also be used for other transformations.
Colour transformations and other image processing like it is the domain of programmable shaders rather than an old fashioned 2D API.
The speed depends on what's in the window, and what the app that owns the window does. For example, you should find resizing a shell window very fast.
I guess he means ReAction-based apps? Those tend to be dog slow to resize. e.g. Media Toolbox (the window showing partitions). Even Calculator (the speed you can resize at is quite slow).
@ChrisH If it is slow, have you installed an alternative workbench theme or do you use the default? While building themes I fond out that buttons with a tiled background or gradiends are slow, especially on the calculator where much buttons are.
Jus interesting for me while building themes, so thanks for a reply also if it is of topic.
Thank you for the clarification. I asked because even oldschool stuff could be very slow using BltBitMapTags().
I hoped that at least 8 bit chunky gfx operations would be accelerated (well, using mask planes for blitting). So I think using WritePixelArray() (and some RLE code writing to CPU memory) would be the better idea...
I hoped that at least 8 bit chunky gfx operations would be accelerated (well, using mask planes for blitting). So I think using WritePixelArray() (and some RLE code writing to CPU memory) would be the better idea...
I'm not sure what your using it for, but if you're planning on doing masked blits on the CPU then you could simply render to a BMF_USERPRIVATE bitmap in RAM using graphics library functions,** and then blit that across to your window/screen bitmap (of identical format and dimensions). That way won't have to write your own blitting routines while still getting the speedup of performing software rendering in RAM. As a bonus, the same code could probably use the classic Amiga chipset on old machines; just remove the BMF_USERPRIVATE flag.
Alternatively, upgrading the code to use 16-bit/32-bit graphics and alpha masks will deliver higher quality...
Hans
** NOTE: All your source bitmaps would be BMF_USERPRIVATE too, so that they're all stored in RAM.
Well, if the source bitmaps are RLE, it´s quite a bit difficult to use graphics.library functions to blit them , but for some other things it might be an easier solution.
@imagodespira I am using a standard OS4 theme. I'm guessing the resizing-speed issue is due to how ReAction handles multiple redraw/refresh requests, since MUI doesn't suffer from this. It's a "problem" I noticed since my first use of OS4.1.
@ChrisH: Thanks for your reply, i just wanted to know what you are using.
@Broadblues: It should not be the task of the coder to update the contents while resizing. Also if your pseudo code works, this should not the aim and i am full to chrisH´s opinion: Reaction is not a rocket in this case ;)
If you compare MUI or Reaction software while resizing, you will see that they do different things. MUI does the refresh not on every single movement of the mouse as Reaction seems to refresh as often as it can... that´s a problem. We have internal tests here where we fixed the problem within the refresh source code of Reaction , it is possible to get a good result. This was only a quick test, there have to solve/clear some dependencies but it is possible and i hope that we get it faster in future.
Resizing Wookie windoes is very slow for example the list of text redraws many times during a resize.
Finding a 'bad' MUI program (which takes a long time to redraw a complex GUI) doesn't disprove that ReAction has a speed issue when resizing windows.
Quote:
Resizing reaction OWB is relative fast as the contents only rerender a few times in a typical drag and resize.
No, even ReAction-based OWB has the speed issue: The speed you can resize the window is limited by the speed it can refresh the window - it makes the mouse feel like it is being dragged through golden syrup (although it's hard for me to test on X1000, as it's quite fast). For ReAction the window does not appear to resize until it's contents have been redrawn, thus limiting the speed it can be resized.
OTOH, MUI programs like Odyssey (etc) can have their window resized as fast as the mouse is capable to move. You can see that the 'slow' speed of redrawing Odyssey does not delay the window being resized. For MUI the redraw of window contents appears to be asynchronouse to the window (borders) being resized.
Asynchronous? Impossible due to the group/object layout mechanism used. How should the layout know how to layout if the window resizing isn´t done? AFAIK the layout domains are dependend on the window´s visible/inner size.
I didn´t use MUI that much, but I presume that it is using the way broadblues suggested within it´s application object/layout loop.
Layouting is deferred until the window resize operation is done (using some timeout).
@Broadblues: It should not be the task of the coder to update the contents while resizing. Also if your pseudo code works, this should not the aim and i am full to chrisH?s opinion: Reaction is not a rocket in this case ;)
Ofcourse with a trivial application like Calculator the coder need not worry about such things, but if you go past that in terms of complexity when you start needing to do custom rendering, the yes the coder does have to get involved.
Forexample: If running MultiViewer in software rendering mode MVer will delay rescaling the image gadget contents till the last of an batch of WMHI_NEWSIZE messages, hardware mode (using compositing) is so fast as to not make that neccessary.
Resizing reaction OWB is relative fast as the contents only rerender a few times in a typical drag and resize.
No, even ReAction-based OWB has the speed issue: The speed you can resize the window is limited by the speed it can refresh the window - it makes the mouse feel like it is being dragged through golden syrup (although it's hard for me to test on X1000, as it's quite fast).
This isn't true at all, I cannot believe that DeferLayout isn't in force with OWB, you can visibly see the contents lagging behind the resize on my SAM 440, particularly if reducing the size of the window.
Quote:
For ReAction the window does not appear to resize until it's contents have been redrawn, thus limiting the speed it can be resized.
Reaction GUIs of any complexity should set the LAYOUT_DeferLayout tag in the top level layout. Layout is then defered, not performed on input.devices task but on the applications process.
The problem could be that with aheavy application like OWB it takes so much CPU to render that it steals time away from the USB mouse and makes it feel jerky.
Quote:
OTOH, MUI programs like Odyssey (etc) can have their window resized as fast as the mouse is capable to move. You can see that the 'slow' speed of redrawing Odyssey does not delay the window being resized. For MUI the redraw of window contents appears to be asynchronouse to the window (borders) being resized.
I see the same as you describe with OWB as Odyssey, except that Odyssey is much faster at rendering pages, especially if any javascript is involved.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
, but for some other things it might be an easier solution.
