[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Buffer size and viewport
Alan Chaney wrote:
> Does anyone have any feel to the relationship between viewport size
> and buffer size and performance? In other words, if I allocate a
> larger buffer than I actually display in the view port, is this likely
> to cause a significant performance issue?
It's not a speed issue (generally) but rather a graphics memory buffer
With front+back+Z buffers - the amount of video memory consumed can get
big. It's worse if you need additional
shadow/ambient-occlusion/motion-blur/blur/HDR buffers since these are
generally sized to match the main buffer size in order that they can
all share the same default Z buffer.
This is especially problematic for mobile devices and older laptops
where video memory is already at a premium...and recalling our earlier
discussion that suggested that compressed textures might be impossible
in 1.0. Worse still, if HTML compositing is being done in OpenGL -
then that too will consume Graphics memory.
IMHO, when the user resizes the window, he's taken himself out of
interactivity and a small fraction of a second of delay to resize the
buffer isn't so terrible.
So I think the buffer should automatically resize - and if it takes a
little time, it's well worth the video memory savings.
There is an argument for only resizing the buffer when it gets larger
than the largest size it has been for this application - and for keeping
it the same size when it shrinks...after all, if you had enough texture
memory at the original size - then you still have enough when it
shrinks. It would be nice if efforts to increase the canvas size
failed and left the buffer the same size when no more video memory is
available since that would be an elegant fallback in most cases.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: