Talk:Hardware overlay

Why this was moved to video overlay? Usually this term is referred to as hardware overlay. If no one objects, I will move it back in few weeks. -Yyy 08:39, 2 June 2006 (UTC)[reply]

Industry uses video overlay to discribe hardware overlay -Dan 8-7-2006

I have no problem with that. But content needs to be worked on. The article should be rewritten as third-person language. Phrases such as you'll generally have better luck using VMR are unprofessional. --so U m y a S ch 08:50, 2 June 2006 (UTC)[reply]

... seems there have been left redirect at hardware overlay, and it can be moved back only by admin. I completely agree about VMR part, but I did not write it. (i do not get its meaning very well, and would like to remove it completely, but then this article would become even shorter). -Yyy 13:53, 16 June 2006 (UTC)[reply]

I moved it back to Hardware overlay. AxelBoldt 21:25, 3 September 2006 (UTC)[reply]

Don't Xgl and AIGLX + Compiz/Beryl on X11 (perhaps even just using a compositing manager) overlay things the same way as Vista now does. 208.101.166.122 02:59, 8 January 2007 (UTC)[reply]

Holy crap

Wow. So many misunderstandings in the Overview section... The checking for clipping is only a small hit on the cpu, there are many many other things going on that make the normal screen slow. For one, text needs to be rendered from vector data, which is much more cpu intensive then checking for overlapping squares. These ovelap checks are trivial stuff.

The whole api that handles draing windows is slow as hell. But that is not because of overlapping windows, it is because it is bloated and does a lot of things to make a windowing system work properly. You can see this if you have only one window covering the whole screen. There will be nothing to check or clip but it will still be slow because the GUI is using a slow access to video memory. Conclusion: the reason of the slowness is not in the checking and clipping.

The overlay is a more direct approach that leaves out most of the stuff that makes the normal gui slow. It is not nessesarily used by only one application, it can be shared. —Preceding unsigned comment added by 83.240.148.59 (talk) 13:53, 1 February 2011 (UTC)[reply]

Hmm. This seems to be a subjective POV regarding MS Windows. While there may be a lot of truth in it, please consider the state of technology when hardware overlay became popular. Back then it was the only viable solution for smooth playback. Obviously overlay can be much more efficient in drawing, color space conversion, scaling, clipping than using the CPU - just set your favorite media player to GDI drawing (or whatever the equivalent is on your platform) and let it play in the background while doing other stuff. Try HD material. You'll still require pretty powerful hardware to not see any difference. If the API used burns the power in other places - that's a different story. -- Zac67 (talk) 15:58, 2 February 2011 (UTC)[reply]

Android overlays

It would be very nice to add Android overlay system description here (as for me I am not sure I am able to do that properly).