TextureCache

[mitchmindtree]

As discussed in #207 a TextureCache could be a good way of solving multiple problems in one hit, however it will take quite a bit of work and internal refactoring.

From #207:

At the moment the draw request is given to the Gl type directly in the .draw method uniquely for each rectangle/glyph. Rather than directly drawing, perhaps we should be building a single texture for each widget which we can then mask etc. This would also mean we could cache the texture and just continue to use the same texture for all widgets whose state does not change, saving a lot of processing while we're at it. I think this may also help us when it comes to dealing with the widget overlap issue (discussed a bit here #145).

Thoughts

• Could be implemented as a Vec<Texture> (stored within the UiContext) where the len of the Vec is equal to the largest UIID
• A widget's UIID is used as a key for retrieving/setting the associated texture.
• If a widget's state has changed, construct a new Texture.
• If a widget's state remains the same, simply use the pre-existing texture.

Benefits

• Provide more control over the way in which widgets are drawn: i.e. clipping/masking. I don't have any experience with doing masking on textures but I'm just assuming that having a widget's view in the form of a texture will make it much easier than our current setup! It may also help us to resolve widget positioning conflicts Defer rendering of widgets in order to resolve drawing conflicts. #145
• A significant improvement in performance as textures need only be updated when a widget is interacted with meaning in most cases only a single widget's texture will be updating at any point in time.

This will be a significant change and will require refactoring of all widgets.

[bvssvni]

If we can render to a texture, then the interface can run on a separate thread than the main thread.

However, it also means we can not have animated effects in the widgets.

[mitchmindtree]

Aahhh I see, would using fragment shaders instead mean we can use animations?

[abonander]

@bvssvni Why can't we animate if we render to a texture? Is it because we would only re-render if the widget state changed? I believe other toolkits have an .invalidate() call for this.

[mitchmindtree]

Yeah come to think of it we should still be able to animate using textures, it's just that animated widgets' textures would be re-rendered every update, which is basically what's happening now anyway.

[abonander]

What texture would we be rendering to? An FBO? I think that would be pretty
fast, even if we allocated one for every widget. Re-drawing every frame
shouldn't hurt too much, especially on modern hardware.
On Dec 9, 2014 12:28 PM, "Mitchell Nordine" notifications@github.com
wrote:

Yeah come to think of it we should still be able to animate using
textures, it's just that animated widgets' textures would be re-rendered
every update, which is basically what's happening now anyway.

—
Reply to this email directly or view it on GitHub
#209 (comment)
.

[bvssvni]

I believe it is as simple as changing the frame buffer target (or something like that). Then, when you do rendering it will render to the texture instead of the screen. When you are done rendering, you can change the frame buffer target back to the screen.

[bvssvni]

Actually there is no need to allocate a texture for every widget, if you keep a texture that fills the entire screen. After rendering to the texture, you can set the source rectangle to the portion of the texture that contains the widget.

Hmm... perhaps we also could do clipping this way, by changing the blending equation to overwrite and then render a transparent color to the areas we want to hide.