Gfx planning worksheet
Vladimir Vukicevic
The Gfx planning spreadsheet is available at
http://spreadsheets.google.com/ccc?key=pF_tMaWf14QxNYvZaPTvsGA&hl=en
-- below is a list of the overall focus areas and a description of
each:
- Full support for layout rendering requirements
Right now, there are a few mismatches between what layout needs and
what gfx/cairo provides. These include (but are not limited to) the
EXTEND_PAD/EXTEND_NONE problems, lack of x- or y-only fill repeat,
lack of source clipping, lack of 16-bit image storage, etc.
This also includes providing links between CSS features and platform
text rendering APIs, to ensure that we can support advanced
requirements from currently unsupported CSS standards.
- Overall software rendering performance
Our baseline rendering speed should be above where it is today,
particularly for more complex workloads.
- Hardware acceleration support on higher-end hardware.
With solid software rendering perf, we are free to focus on hardware-
accelerated rendering on medium to high end hardware, without worrying
about how to scale down to low end hardware. This does not preclude
us from taking advantage of some parts of hardware optimization on low
end hardware, but means that we can look at doing partial acceleration
where it makes sense.
- Improving widget backends to support future work
This includes supporting removal of child widgets and hopefully
simplifying the widget API, supporting process separation, and adding
and improving support for additional widget backends as needed.
- Cleanup
One of the things that's fallen off the plans list for the past few
cycles is getting rid of old and deprecated Gfx interfaces as well as
simplifying existing APIs (especially for images). We need to make
sure we are able to take that on.
One of the things that's missing from the list above is any work
regarding Harfbuzz/glyph selection unification across platforms. This
does not seem to be a priority at this time; at one point we thought
it would be important for mobile, but mobile is not pressing for it
currently. However, we might need this to support some of the finer-
grained CSS3 text features... if we need to make sure that gets on the
list, please let me know.
Let me know if any of these don't make sense, or if there are any that
we missed. Also, please let me know if the relative priorities of
items make sense.
Thanks!
- Vlad
Question
What’s the relationship between canvas 3D and hardware acceleration of
Cairo?
--
>: ~
Robert O'Callahan
> Right now, there are a few mismatches between what layout needs and
> what gfx/cairo provides. These include (but are not limited to) the
> EXTEND_PAD/EXTEND_NONE problems, lack of x- or y-only fill repeat,
> lack of source clipping, lack of 16-bit image storage, etc.
>
> This also includes providing links between CSS features and platform
> text rendering APIs, to ensure that we can support advanced
> requirements from currently unsupported CSS standards.
I think to get really nice curved borders where the adjacent sides have
different colors and widths, and we smoothly blend colors and adjust
widths along the curved corner, we need some kind of cairo support for
advanced stroking effects.
> One of the things that's missing from the list above is any work
> regarding Harfbuzz/glyph selection unification across platforms. This
> does not seem to be a priority at this time; at one point we thought
> it would be important for mobile, but mobile is not pressing for it
> currently. However, we might need this to support some of the finer-
> grained CSS3 text features... if we need to make sure that gets on the
> list, please let me know.
It's essential for CSS3 text features. We've also discovered serious
limitations/bugs in Uniscribe, in particular its inability to shape
dynamically loaded Opentype CFF fonts. I definitely want us to invest in it.
Rob
Vladimir Vukicevic
None, really -- though once we have hardware accel rendering ot he main
browser, Canvas 3D speeds up as well since the final display-on-screen
step remains entirely on the graphics card.
- Vlad
Mithgol the Webmaster
ROC> I think to get really nice curved borders where the adjacent sides have
ROC> different colors and widths, and we smoothly blend colors and adjust
ROC> widths along the curved corner, we need some kind of cairo support for
ROC> advanced stroking effects.
Sounds as if you're going to ruin the design technology known as CSS triangles
which relies on the fact that the line (in the corner between adjacent borders
which have different colors and width) is a straight diagonal line (no curves,
no color blending, just a mere humble anti-aliasing).
For more details, see the following tricks based on pure CSS:
http://tantek.com/CSS/Examples/polygons.html
http://www.designdetector.com/tips/3DBorderDemo2.html
http://fastcoder.org/demo/roundAngles.html
With best Fidonet 2.0 regards,
Mithgol the Webmaster.
.. 226. I will have a staff of competent detectives handy.
Dao
Markus Stange
> And about 10:00 27 Mar 09 it was written from Robert O'Callahan to All:
>
> ROC> I think to get really nice curved borders where the adjacent sides have
> ROC> different colors and widths, and we smoothly blend colors and adjust
> ROC> widths along the curved corner, we need some kind of cairo support for
> ROC> advanced stroking effects.
>
> Sounds as if you're going to ruin the design technology known as CSS triangles
> which relies on the fact that the line (in the corner between adjacent borders
> which have different colors and width) is a straight diagonal line (no curves,
> no color blending, just a mere humble anti-aliasing).
As far as I understand it, the transition effects Roc described will
only apply in the curved part of the corner, which will only exist when
you use border-radius.
-Markus
Robert O'Callahan
> As far as I understand it, the transition effects Roc described will
> only apply in the curved part of the corner, which will only exist when
> you use border-radius.
That is correct.
Rob
Mithgol the Webmaster
Da> I don't see any practical use in the examples you linked to.
They facilitate creating triangles and trapezia (and thus arbitrary polygons),
without any other means than CSS; i.e. the site's author does not have to learn
and use VML or canvas or SVG, and the browser may be one of those which do not
know of VML or canvas or SVG.
With best Fidonet 2.0 regards,
Mithgol the Webmaster.
.. 136. If I build a bomb, I will make every wire red.
robi...@googlemail.com
wrote:
> They facilitate creating triangles and trapezia (and thus arbitrary polygons),
> without any other means than CSS; i.e. the site's author does not have to learn
> and use VML or canvas or SVG, and the browser may be one of those which do not
> know of VML or canvas or SVG.
There aren’t many of those browsers left are there? Firefox has
supported canvas since Firefox 1.5, Safari since 1.3, Opera’s had SVG
support since 8.0 and IE’s had VML for years.
Going wildly off topic here though :)
Robert O'Callahan
> I think to get really nice curved borders where the adjacent sides have
> different colors and widths, and we smoothly blend colors and adjust
> widths along the curved corner, we need some kind of cairo support for
> advanced stroking effects.
Oh, of course the worst case is that the two borders have different
styles (e.g. one dotted and one dashed).
Rob
Robert O'Callahan
> http://spreadsheets.google.com/ccc?key=pF_tMaWf14QxNYvZaPTvsGA&hl=en
> -- below is a list of the overall focus areas and a description of
> each:
>
> - Full support for layout rendering requirements
>
> Right now, there are a few mismatches between what layout needs and
> what gfx/cairo provides. These include (but are not limited to) the
> EXTEND_PAD/EXTEND_NONE problems, lack of x- or y-only fill repeat,
> lack of source clipping, lack of 16-bit image storage, etc.
Oh, another thing is 3D transforms. SVG's getting them, CSS's getting
them, Webkit's got them, we'll need them.
Rob
Christopher Blizzard
transforms might be cheaper - is that reflected in the spreadsheet?
--Chris