If I use Reaction for a GUI to my program, am I by definition using hardware compositing, assuming I have a compositing supported graphics card? or do I need to do something else to get hardware compositing?
And when Mesa becomes available, will Reaction transparently support whatever added benefits offered by Mesa compared to current hardware compositing? Or will something special need to be done for a Reaction GUI to benefit from the appearance of Mesa?
Does/will mesa have any further benefits beyond current compositing for a GUI and other 2d graphics stuff?
The most likely answer to this (seeing as Mesa is not yet available) is that any OS components that can use it, will, by default.
An application programmer should not need to worry about such things in the GUI toolkit.
Simon
I'm asking as someone interested in working on a foreign API wrapper. I'm not sure if thre's a difference between that and an application, but I do want to take best advantage of hardware acceleration for windows, screens, whatever available to us. And would rather not go a long ways down one road that will only become obsolete and wrong before I finish.
I've seen other recent discussions elsewhere mention using Cairo for hardware compositing. Should I be aiming at Cairo for my Amiga-native target, or does Reaction have the same compositing capabilities?
Once Mesa arrives, will Reaction become nothing more than a wrapper to that? Would it thus be better to aim at Mesa directly now, as the way I progress on things it'll probably be out before I get significantly far with anything.
I'm just trying to get an idea of how things fit together, and what the best thing to do is.
@billt
ReAction is a set of standardized "building blocks" (classes) from which you construct a GUI. It's not a graphic library so it can neither replace Cairo, nor wrap around Mesa.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
@billt
I'd say ReAction would have more! ReAction has access to the systems resources which will take care of hardware rendering.
As I understnad it Cairo uses software rendering on OS4 or at least doesn't make full use of the hardware rendering features so it would be less of a gain to use it.
But what would API wrapper be for? GUI specific or something else? We can use MUI as an example of ab external API wrapper for GUI bullding.
I'd like to try and help out on WxWidgets wrapper. It's mostly GUI I guess, but does have OpenGL calls, networkign, pretty much anything. But Reaction part is of course GUI.
I guess I'm asking these questions because we are seeing traditional GUI windows making more use of graphics hardware. Going beyond 2d line and shape functions to using 3d for what we use as a 2d window to scale it easier than an overlay, etc. So for all things that we could have accelerated using more recent 3d methods than old 2d methods, I want to take advantage of this as much as I can for WxWidgets GUIs, be they GL or 2d things.
But for discussions I've seen about our current hardware compositing, it seems Cairo is what gets named, not Reaction, so I began to wonder if Cairo got some special treatment early on that Reaction was still waiting for. And when Mesa comes, will Cairo or Reaction or whatever be the first to benefit from any additional hardware accleration due to that.
Reaction I think is the obvious target for a GUI API wrapper on OS4, regardless of accelerators. In time, if Reaction doesn't support something but it gets added later, anything using Reaction will magically get faster on that feature.
I guess I'm curious, at what level does this hardware compositing or other acceleration fit in for our graphics stuff? Do Cairo and Reaction and anything else each have to support it themselves somehow, or is it now a fundamental way of doing things at our lowest levels of graphics support in teh OS, and thus any grapics related thing uses hardware compositing/acceleration without needing to know about it?
Such as, I know P96 drivers can have 2d hardware accelerated things, but P96 does not do 3d. How do P96 applications benefit from modern 2d methods using 3d hardware features or whatever it is that we call compositing? Things like that.
@billt
Compositing is just another function in the graphics libarary: CompositeTags(). As such, and Reaction gadget/image can use it to render itself.
With MESA, MiniGL or Warp3D, you would render to an off-screen bitmap, a Reaction gadget/image could render to an offscreen bitmap and blit it onto the gadget's/image's bitmap (which is part of the window's own bitmap). Windowed MiniGL/Warp3D applications work this way too.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
@billt
Good to hear that someone is interested in getting the GUI part of wxWidgets working. If you do have a go, I recommend writing a native version of wxGraphicsContext and use the wxDC wrapper around it for the graphics rendering. This is how it's done in the MacOS X port, and it is a better approach. The wxDC API is archaic (based on the old Windows GDI), whereas wxGraphicsContext includes compositing.
You can worry about the Reaction part later.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
By native for wxGraphicsContext I assume you mean to call Picass96 and/or graphics.library stuff? Yet more stuff to read up on!
I have an old DDK for P96, is everything I might need for it in the Hyperion SDK to use P96, or do I need to look elsewhere for that? (It's been ages...) Ah, yes, I see it in the autodocs dir now. Sorry...
If I'm using P96, is there anything to call outside of P96, or are we P96-only now for graphics things? (ie/ graphics.library IS P96, etc, or do I use P96 ofr certain calls and other things for other calls?)
If I understand things correctly, is this perhaps a section that may in the future benefit from going direct to mesa or am I just insisting to bark up the wrong tree like that?
Eh, no autodoc for reaction there. At least I'm reading them in Linux now. And I've dug my RKM and a few other books out of storage as well.
"Reaction" is the collective term for the BOOPSI objects supplied with AmigaOS4+, so if you want autodocs, you need to consult the appropriate doc for the object of interest.
I would suggest you start of with window_cl.doc, as that gives a reasonable background into BOOPSI and how it all ties together.
Simon
OK, for a dummy like me, is there a list of these objects that make up what you refer to as Reaction then? For us newbies, how do we know what is and what is not included, and where else to look for them?
@billt
Stick to the graphics.library if you can. Only use Picasso96 if you absolutely have to. The graphics library is still the official graphics API, with Picasso96 patching it to use graphics cards. Picasso96API.library was never meant to be an official replacement.
Not necessarily MESA. It is possible that something like Cairo (a 2D graphics lib) could be accelerated using Gallium in future, which would be more appropriate. In the meantime, stick to the graphics library if you can.
Have you checked out trixie's blog on this website about Reaction? It's pretty good. There are also some examples on os4depot (just search for "reaction"), but they might use old coding styles that trixie's blog posts discourage. The examples could still prove useful.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
@ billt
CLASSES:
ARexx
PopUpMenu
Requester
Window
GADGET SUB-CLASSES:
Button
CheckBox
Chooser
ClickTab
ColorWheel
DateBrowser
FuelGauge
GetColor
GetFile
GetFont
GetScreenMode
GradientSlider
Integer
Layout
ListBrowser
Page
Palette
Partition
RadioButton
Scroller
SketchBoard
Slider
Space
SpeedBar
String
TextEditor
Virtual
IMAGE SUB-CLASSES:
Bevel
BitMap
DrawList
Filler
Glyph
Label
PenMap
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
Thank you again Trixie!