Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
153 user(s) are online (78 user(s) are browsing Forums)

Members: 2
Guests: 151

Maijestro, Templario, more...

Headlines

 
  Register To Post  

« 1 (2)
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Quite a regular
Quite a regular


See User information
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.

http://www.osdever.net/FreeVGA/vga/vgareg.htm#color
http://wiki.osdev.org/VGA_Hardware
http://www.osdever.net/FreeVGA/vga/attrreg.htm


Retired
Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@AmigaBlitter
Quote:
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.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@Hans Quote:
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).

Author of the PortablE programming language.
Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Just popping in
Just popping in


See User information
@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.

Regards,
Thomas

Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Just popping in
Just popping in


See User information
@Hans

What about BltBitMapTags() with masking into a destination bitmap with same attributes? Accelerated?

Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@whose

Quote:

What about BltBitMapTags() with masking into a destination bitmap with same attributes? Accelerated?

You mean using a mask bitplane (BLITA_MaskPlane)? I don't think so.

Do bear in mind that it also depends on the graphics hardware. For example, Radeon HD cards can't handle BLITA_Mask being anything other than 0xFF.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Just popping in
Just popping in


See User information
@Hans

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...

Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@whose

Quote:
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.

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Just popping in
Just popping in


See User information
@Hans

Thx for the hints

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.

Thx!

Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@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.

Author of the PortablE programming language.
Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@ChrisH

Quote:

I'm guessing the resizing-speed issue is due to how ReAction handles multiple redraw/refresh requests, since MUI doesn't suffer from this.


I think this is highly application dependent and not at all Reaction Verses MUI.

Resizing Wookie windoes is very slow for example the list of text redraws many times during a resize.

Resizing reaction OWB is relative fast as the contents only rerender a few times in a typical drag and resize.

It's all down to how you handle the window resize messages, whether you deal with every one, or just the last in any one batch.

psuedo code:

slow

while getmsg {
case window resize render.
}

faster

need_resize = false;
while getmsg {
case window resize need_resize = true;
}
if need_resize render.


Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Just popping in
Just popping in


See User information
@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.


Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@imagodespira

Very interesting
This one is a long standing issue, hope it can be fixed for the next update...

Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@broadblues Quote:
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.

Author of the PortablE programming language.
Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Just popping in
Just popping in


See User information
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).

Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@imagodespira

Quote:

@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.




Go to top
Re: What parts of AmigaOS4 graphics are hardware accelerated?
Home away from home
Home away from home


See User information
@ChrisH

Quote:

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).


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.


Go to top

  Register To Post
« 1 (2)

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project