@thread

ok. There is talk of overlay in SO many threads, it really deserves a thread of it's own. The real concern people are expressing is a need for increased speed of the graphics display, through whatever method is implemented.

There is a current discussion on Amiga.org that details some valid points.

I'll paste the original posts (credit Amiga.org) to get things started.

Crumb quote:

Quote:

No overlay??? In 2012? Really? IMHO overlay is a very basic feature much more important than 3d support.

Karlos response:

Quote:

It's 2012. Overlays are pretty much obsolete - the chances are the feature you are thinking of is emulated on your graphics card using 3D support anyway. Let's see why: Overlay: separate display region with independent colour format and resolution from main framebuffer, intended for the display of video streams. + No software YUV RGB conversion necessary + No software scaling/filtering necessary These were definite boons back in the 90's, but there are drawbacks too - Generally only one overlay available on supported hardware - Overlay typically occludes framebuffer and can't be part of any graphics pipeline or windowing architecture. It's basically "on top" or not at all. - Limited video processing available, usually only colour properties can be adjusted. The alternative to this is video texturing, where a YUV video stream is applied as a texture map to a rectangle primitive. + No software YUV RGB conversion necessary + No software scaling/filtering necessary So far just as good as an overlay, but there's more: + As many concurrent video streams as bus bandwidth / texel fillrate allows + Render target is a bitmap, can be used as part of any graphics pipeline or windowing architecture. Does not float above framebuffer and is compatible with both traditional and compositing windowing methods. + 2D/3D transformations possible + Shader postprocessing possible (on hardware that has them, which in 2012 is everything), virtually limitless potential for colour correction, sharpening, deblocking, deinterlacing, wacky artistic effects etc. On my linux box, my nvidia card can handle many video streams at once, rendering them via this method and I can still do all the silly compiz zoom, 3D rotating box and other nonsense with no loss in speed while the video continues to render smoothly in each window. It's not even a new idea. The Permedia2 doesn't have a dedicated overlay, instead supporting YUV textures. Due to the lack of fill rate (and on the Amiga, slow buses), you are pretty much restricted to one or two streams. I really don't think you are missing much if you don't have a genuine overlay on anything like the HD4xxx series or above but you can leverage the 3D hardware instead.

Itix portion on same topic:

Quote:

I really don't think you are missing much if you don't have a genuine overlay on anything like the HD4xxx series or above but you can leverage the 3D hardware instead.

Fab:

Quote:

Sure, newer graphic cards have other (and more modern) ways to implement some "overlay" feature, and who cares how it's done, actually (more than a decade ago, cgxvideo supported "overlay" on cvppc/bvppc by using the permedia2 3d functions too). The point is that current applications use p96pip/cgxvideo API and without it, video players are really SLOW, since they have to fallback on RGB conversions and WPA blitting (which is apparently slowish on OS4). The lack of overlay and fast PCIe/AGP transfers is the reason why AROS MPlayer is much slower than MorphOS MPlayer on a similar setup. Actually, on a recent machine, AROS spends much less time to decode a full 1080p frame than to blit it... That's really funny if you ask me ! On MorphOS, displaying a decoded 1080p frame takes something like 15ms on a mac mini, while on AROS, it used to take more 50ms (on much more powerful hardware). Anyway, the problem with RadeonHD is it gets quite harder to have this "overlay" functionality since the whole 3d machinery has to be implemented first.

Sorry about posting the quotes, but often people do not follow links and I think this issue has importance to most people here.

start of discussion in case it continues there

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

come now you left out my reply to Karlos

I of course was only endorsing his closing statement

_________________
~Yes I am a Kiwi, No, I did not appear as an extra in 'Lord of the Rings'~
1x AmigaOne X5000 2.0GHz 2gM RadeonR9280X AOS4.x
3x AmigaOne X1000 1.8GHz 2gM RadeonHD7970 AOS4.x

@number6

I was just going to put up a little bit similar summary.

Overlay is not interesting when there are better ways to do similar thing + more.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@number6

Quote:

The real concern people are expressing is a need for increased speed of the graphics display

Hmmm... strange... me good old miggies have always run at the same speeds for their graphics display (not even slowed down despite being 20 odd years old) and they still run perfectly well at the same speed even in this day and age...

Mind you I still use good old CRT monitors and not them new fangled flat screen LCD wot nots with their built in motion blur...

Hey, maybe that the problem, it not a faster graphics display that they need, it's simply the fact LCD monitors are naff and can't even keep up with bog standard classic A1200 screen modes, simple solution... switch to a decent good old fashioned CRT and you won't need even faster graphics displays which will only cause even more blurring as your LCD fails even more to keep up with it...

That's the trouble with new fangled modern LCD wot nots, they look cool as a piece of furniture but sadly they aint half as good as good old fashioned analogue technology when it comes to the purpose they were made for... ie: simply displaying a smooth moving picture...

PS: No need to thank me for this wee bit of helpful info...

_________________

@thread

I recall posting about starting multiple A/V files in the past using Frogger68k and PPC. At the time I mentioned there were individual controls for the window itself. You could adjust brightness, contrast, saturation..

Will any new methodology employed allow this or are there any plans to go in this direction?
The former advice I received to turn up brightness on my monitor was erm...so wrong. Once you create your workbench, it's really only the setting for the A/V file you want to affect. Heh.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

I still use overlay on my pc because as soon as you start operating on textures it kicks the 3d clocks in and the card makes noise. Not a major caveat though I admit.

_________________
Fraggle

- insert profound text here -

Is OS4 composition can be involved for that purpose until we get real 3D drivers?
It shows really good performances with games and 3D.

Petrol.

@petrol

Quote:

Is OS4 composition can be involved for that purpose until we get real 3D drivers? It shows really good performances with games and 3D.

Interesting that you should mention that.

Alain Thellier just made a post in the Amiga.org thread related to that.

Quote:

Using compositing for scaling/filtering/rotating a square texture (a bitmap) is easy... The only problem is that compositing dont support YUV directly... So it will remain the YUV to RGB conversion

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

I like graphics programming. I would like to see some example for any of the mentioned features "scaling/filtering/rotating a square texture (a bitmap) is easy..."

_________________
retired

@number6

Quote:

number6 wrote: @petrol Quote: Is OS4 composition can be involved for that purpose until we get real 3D drivers? It shows really good performances with games and 3D. Interesting that you should mention that. Alain Thellier just made a post in the Amiga.org thread related to that. Quote: Using compositing for scaling/filtering/rotating a square texture (a bitmap) is easy... The only problem is that compositing dont support YUV directly... So it will remain the YUV to RGB conversion #6

This is really quite an odd thread...

It's turning into a "live update" of what's being posted on Amiga.org for folk who can't figure out themselves how to go there and just read the thing...

Is this a new "trend" or "fad" or is there simply nothing being said in this thread that's worth reading and you have to nick posts from another site to keep it going... strange... really, really strange... :-/

_________________

@number6

Good job collecting the info.

For what it's worth, I completely support Karlos on this. Overlay looks like a cool idea until you try something as funky as playing a video while playing a video (DVD + flash open at the same time, for instance). Then it becomes a matter of "which video did I open first".

Putting in man-hours to support overlay now just doesn't make sense.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@Franko

Hey, he's tying up threads, as the "what, no overlay" thing really is spinning out of proportions. You however is not performing any function at all.

Nor am I, probably. Just sayin'

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@Franko

Hard to believe, but some people will read the contents of a post but not follow a link.
It's always been a problem to troubleshoot or have a conversation of a wider scope without jumping from site to site.
Since the last post was from a developer, I thought it warranted being repeated.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Quote:

number6 wrote: @Franko Hard to believe, but some people will read the contents of a post but not follow a link. #6

Hard to believe... not really as I've kinda gathered by now that some folk are just too lazy to click on a link...

In all seriousness though (which is rare for me), it really doesn't say much for the image of a site when your reduced to posting "almost live" what is being said on another site...

I mean surely the members here with something to say on the subject can come up with their own ideas/ comments/ posts instead of just reading here what someone else said elsewhere a few minutes ago...

Just seems a wee bit strange to me that's all...

Switching back to daft mode and I'll leave you alone...

_________________

@Franko

The user here asked a question about compositing. By pure chance a developer was talking about the identical subject on a.org.
That's why I reposted that particular reply...to help the user.
I'll go slap myself now for trying to help.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

ok thanks for the infos, now everything is much clear, at least for me, but in the meanwhile that os 4.2 will arrive with Gallium and all that it need to have overlay with texture and so on, why do not implement overlay in the traditional way?

_________________
GDG-Entertainment
OS4Games
Iksnet
Bitplane

@number6

Quote:

I really don't think you are missing much if you don't have a genuine overlay on anything like the HD4xxx series or above but you can leverage the 3D hardware instead.

I didnt write that. It is a quote from Karlos.

In Frodo MorphOS port there is switch to use either overlay or tinygl (YUV conversion of course is not needed, just scaling and filtering). Overlay method is faster and easier to setup than OpenGL method.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@number6

ooh, ooh. Can I slap too? Haven't slapped anyone in ages and I'm starting to feel an itch here

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@itix

Quote:

In Frodo MorphOS port there is switch to use either overlay or tinygl (YUV conversion of course is not needed, just scaling and filtering). Overlay method is faster and easier to setup than OpenGL method.

Maybe you can answer this.
Is it necessary for data to be in YUV form to facilitate "on the fly" changes to brightness, contrast, tint, saturation, etc. to an A/V file?
Does one method have an advantage over another?

Old quote from Fab (2006), so I don't know if he's looked into this since:

Quote:

Most of the video drivers that implement contrast/brightness/whatever in mplayer use the display driver abilities, so there's no additional processing there, apparently. But i have absolutely no idea if it could be done that way with our OSes. I also don't know how Frogger implemented it.

#6

@Olegil

I hear ya'.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@olegil
I second thanking number6 for collecting the info. Not everyone has time to follow (and posting in...) every single thread on teh internets (looks idly in Franko's direction).

Last edited by ChrisH on 26-Jun-2012 at 06:42 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...