FBOs and window framebuffers generally have different pixel formats, and
so require separate pipeline configurations.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Direct3D requires GPU vertex attribute structs sizes be a multiple
16. A cleanup commit removed an unusued field, and broke that
assumption.
Fixes: https://todo.sr.ht/~eliasnaur/gio/422
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There are no public API that uses f32.Rectangle anymore. Move Rectangle
to an internal package for internal use.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
driver.Device.NewFramebuffer doesn't provide additional information over
driver.Device.NewTexture, so Texture can hold its (optional) framebuffer
on behalf of the renderers. Metal don't even need a separate framebuffer
object.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Vulkan doesn't support changing uniforms during a render pass. However,
push constants *can* be changed. The gio-shader repository was changed
to use push constants instead of uniforms, this change implements the
corresponding driver and renderer change.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Modern GPU API such as Metal and Vulkan use explicit render passes
and command buffers for recording rendering commands. They don't have
global state; each render pass starts with a clean set of bound
textures, pipeline etc.
Change our GPU abstraction to better match newer API and modify our two
renderers to explicitly describe their render passes.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Modern API such as Metal and Vulkan want clients to compile expensive
state changes into pipeline objects. Change our GPU driver abstraction
to match, thereby paving the way for future drivers.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The default renderer tracks opaque rectangle draw operations and render
them front-to-back with a z-buffer to omit overdraw. However,
- Overlapping opaque rectangles are rare in a GUI, and the most common
instance, a solid window background, is already optimized to a glClear.
- A z-buffer is memory heavy.
- We conservatively assume a 16-bit depth buffer, which limits the
number of drawing operations to 64k (#127).
- Depth buffer support makes GPU ports more complex, especially for
upcoming ports (Metal, Vulkan).
- The compute renderer doesn't use z-buffers.
This change removes the optimization; a follow-up removes GPU backend
support.
Fixes gio#127
Signed-off-by: Elias Naur <mail@eliasnaur.com>
All functions left in the old package unsafe were provided byte slice
views of other types. Rename the package accordingly and avoid a name
clash with the standard library package unsafe.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There are no longer any importers of package backend outside of
gioui.org/gpu. Move it internally, and rename it to the slightly more
specific "driver" while we're at it.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The size is unchanged, but a corner is no longer encoded as two
16-bit ints (2*2 bytes); it is encoded as a float32 (1*4 bytes).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Reintroduce support for offset in stencil vertex so we can reuse
cached values if the only difference in transform is offset. Split
current transform into a pure-offset part and the rest and use
only the complex part as cache key.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
Add support for affine transformations. The key changes are outlined
below.
- Painting/clipping with rectangles is handled by, for complex
transforms, creating clipping paths representing the transformed
rectangle and using a larger bounding box. Cover/Blit shaders updated
correspondingly to correctly map texture cordinates from the new
bounding boxes.
- Since path splitting must happen on CPU the transforms must happen CPU
side as well - offsets removed from shaders.
- Complex transforms will lead to different path splitting which means
that GPU arrays can no longer be cached if the transform has changed.
Thus the current transform is added as a key to the cache.
- Add a public API to op for setting Affine transformations.
There are a number of optimizations that could be explored further but
which are left out now:
- Caching also of CPU operations (e.g path splitting & transforms) and
not only caching the GPU arrays.
- Allow for re-use of cached GPU vertices if the transformation change
is a pure offset / scaling since the splitting is then the same.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
This is a first step towards supporting affine drawing transforms.
The rendering algorithm relies on quadratic curves that do not cross
x = 0 more than once, thus curves must be split after any rotation/shear
transforms. Move this logic and the generation of vertices to package gpu.
Also close all curves and draw zero-width edges as preparation for
transform since the will no longer implicitly be vertical with no
effect.
This commit will severely affect performance since vertexes are now
transformed also for cached items, using cpu resources.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
Specifying the clear color and depth at the time of clearing is
less error prone and a better for modern GPU APIs. As a bonus, we
can get rid of the BufferAttachment type.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Uniform buffers are byte slice backed by Go structs. However, if a uniform
buffer value is embedded in a larger structure with pointers, the Cgo
pointer checker will complain. Avoid the error by moving the uniform
values into separate structures.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
DefaultFramebuffer was set up at Backend creation time, which is
difficult to predict. Instead, let GPU query and cache the current
FBO when created.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Along with ReadPixels in the next change, a Framebuffer with depth is enough to
implement screenshot functionality on top of any Backend.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
"handling" means panicing, but at least the panicing is moved up
a layer, leaving future changes to do it properly in GPU.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
OpenGL doesn't care if the texture to a framebuffer changes, but
Direct3D does. Change Backend to better match both APIs.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Direct3D needs to know the texture bind usage up front, in particular
whether the texture is going to be used as a render target.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
It serves no purpose other than paranoia. Perhaps buggy drivers exists that
require unused texture slots cleared before drawing to a texture, but if so the
workaround belongs in the GL backend.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Walter Werner SCHNEIDER