<div style="direction: ltr;"><span class="gmail_quote">On 3/8/07, <b class="gmail_sendername">Daniel Amelang</b> <<a href="mailto:daniel.amelang@gmail.com">daniel.amelang@gmail.com</a>> wrote:</span><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<span class="q">On 3/7/07, Eero Tamminen <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:eero.tamminen@nokia.com">eero.tamminen@nokia.com</a>> wrote:</span><br><span class="q">> Err. Translucency means compositing and keeping the composited items in
</span><br><span class="q">> memory. Due to additional memory accesses needed for this, it would be</span><br><span class="q">> slower (and take more memory) regardless of how "accelerated" it would</span>
<br><span class="q">> be.</span><br></blockquote><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><div> </div></blockquote><span class="q">
</span></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Keeping the composited items in memory is not necessary. After you<br>composite, you can (and often) just keep the final result around. It
<br>is true that certain applications may cache the intermediate surfaces<br>to optimize performance, but that's where the hardware acceleration<br>comes in. If we had it, we might not need to keep those intermediate<br>
surfaces around as much, and thus you would actually use _less_ memory<br>if you had hardware acceleration.</blockquote><div><br>This doesn't make any sense. What if the surfaces are moved in relation to each other? Then the compositing has to be done again. I've never heard of a system that ignores the intermediate surfaces. I've heard of systems that let the graphics subsystem--ie hardware--take care of this, but in that case it's just shifting from system memory to graphics memory. I believe in our case, it's the same memory, so it's a wash.
<br></div><br><div><span class="gmail_quote">On 3/8/07, <b class="gmail_sendername">Daniel Amelang</b> <<a href="mailto:daniel.amelang@gmail.com">daniel.amelang@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 3/7/07, Eero Tamminen <<a href="mailto:eero.tamminen@nokia.com">eero.tamminen@nokia.com</a>> wrote:<br>> You can see this even on Desktop, just ask how many gamers are happy<br>> with integrated graphics cards which share memory with the rest of the
<br>> system instead of having (hundreds of megs) of their own memory in which<br>> to store textures etc. and in where the operations can be done without<br>> loading the memory bus of the rest of the system (downside is that all
<br>> this costs, adds to the computer power consumption & heating). :-)<br><br>I don't totally agree here either. It sounds like you're saying that<br>the hardware acceleration won't get you much unless you have dedicated
<br>video memory.<br><br>Here's a counter-example: the macbook uses an integrated graphics card<br>to do all of its fancy accelerated UI effects, including translucency.<br>Yes, the macbook is not a gaming machine, but that's not the issue,
<br>here. The issue is that hardware-accelerated graphics enable advanced<br>user interfaces, even w/out dedicated video memory.</blockquote><div><br>Umm.. the MacBook dedicates a significant portion of system memory for integrated graphics. Where most systems that use integrated graphics allow variable amounts of memory from 8mb up and usually default to something like 32mb, the Macbook doesn't allow anything less than 80mb dedicated to graphics processing. I think that's a poor counter example.
<br></div><br></div>--Paul<br>