Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draw front-to-back #77

Closed
kkaefer opened this issue Sep 11, 2013 · 1 comment
Closed

Draw front-to-back #77

kkaefer opened this issue Sep 11, 2013 · 1 comment
Labels
performance ⚡ Speed, stability, CPU usage, memory usage, or power usage

Comments

@kkaefer
Copy link
Member

kkaefer commented Sep 11, 2013

Draw layers front to back so that we can use the depth buffer to cull completely opaque fragments.

@ansis
Copy link
Contributor

ansis commented Oct 3, 2013

Its probably worth also trying to sort by state instead of just front-to-back as described in these slides. Which is faster depends on where the bottleneck is.

I'm seeing potential conflicts with out of order rendering and current approaches for anti-aliasing and degenerate triangles:

For example, two lines interesect. If the top line is drawn first, its antialiased edges will also be drawn and written to the depth buffer. The underlying line won't be drawn to these pixels, causing a crack. It would be fairly easy to fix. Just draw anti-aliasing separately in a later call. This could have performance implications for line rendering.

Right now degenerate triangles work by increasing the z value of the degenerate vertex to something > 1.0, so that all fragments will have interpolated z values > 1.0 (drawn features always have a z of 1.0). If drawn features have a z < 1.0, then parts of degenerate triangles could still be drawn. This could be worked around by keeping z values as close to 1.0 as possible (determined by depth buffer precision) and increasing the value for degenerate vertices.

@kkaefer kkaefer closed this as completed in 63e9f71 Dec 4, 2013
bensleveritt pushed a commit to bensleveritt/mapbox-gl-js that referenced this issue Oct 24, 2016
Drawing and editting refactor - closes mapbox#77 and mapbox#21
lucaswoj pushed a commit that referenced this issue Dec 13, 2016
instead of using GL_INVERT, we increment/decrement the pixels so that we can
detect nonzero areas. this means we can now handle overlapping polygons.
optionally, you can switch back to even-odd filling if desired (needs to be
exposed to the stylesheet).

in the same turn, it switches the clipping from the depth to the stencil buffer
so that we don't need to request a depth buffer at all. prior to rendering,
it masks the 0x80 bit to indicate the current tile extent.

it also switches to front-to-back compositing, meaning that things drawn later
in a frame will appear *behind* what is already visible. this allows us to use
the stencil buffer to mask areas that are fully opaque so that we can cull
fragments in those areas early on.

fixes #55
fixes #77
fixes #177
lucaswoj pushed a commit that referenced this issue Jan 11, 2017
Promote glyphs to a top level element
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance ⚡ Speed, stability, CPU usage, memory usage, or power usage
Projects
None yet
Development

No branches or pull requests

2 participants