You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just managed to get our application running on the shape rasterizer branch, and played around with it a bit. Looks really powerful so far. In #44 you mentioned that a border-width and border-color would not be necessary when this is implemented - how exactly would that work for variable size elements? (eg. resizable windows)
Also, am I right to assume that the srect, sglyph, sblur etc are "commands" that are executed in sequence? Seems like a lot of cool things could be chained like that.
Very nice so far! 👍
The text was updated successfully, but these errors were encountered:
The srect, sglyph, sblur (etc.) attributes are commands (as you expected) to the stencil buffer, that is then rasterizer using the color command. The target is a bitmap fragment. So you can f.ex compose a border fragment and border element, and reference it from anything that wants a border. If you make it white, you can colorize it with img-color (instead of generating one for each color of border you need). It can be outset by using "expand" as usual.
BoxStretch and BorderStretch will take care of the variable size stuff (just like Androids "9-patches"), just like with fragments loaded from image files.
I just managed to get our application running on the shape rasterizer branch, and played around with it a bit. Looks really powerful so far. In #44 you mentioned that a
border-width
andborder-color
would not be necessary when this is implemented - how exactly would that work for variable size elements? (eg. resizable windows)Also, am I right to assume that the
srect
,sglyph
,sblur
etc are "commands" that are executed in sequence? Seems like a lot of cool things could be chained like that.Very nice so far! 👍
The text was updated successfully, but these errors were encountered: