[haiku-bugs] Re: [Haiku] #17538: WebPositive SVG stroke rendering
- From: "Haiku" <trac@xxxxxxxxxxxx>
- To: undisclosed-recipients: ;
- Date: Wed, 16 Feb 2022 16:02:48 -0000
#17538: WebPositive SVG stroke rendering
-------------------------------------+-------------------------------------
Reporter: thebuck | Owner: pulkomandy
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: | Version: R1/Development
Applications/WebPositive | Keywords: SVG stroke line
Resolution: | rendering
Blocked By: | Blocking:
Platform: All |
-------------------------------------+-------------------------------------
Comment (by pulkomandy):
Thanks for your time and efforts investigating and researching this.
Do we really want to channel an aggressively introspective web browser
through interface kit and app_server to reach agg? The same shape data is
passed multiple times for filling, stroking, hit testing, and yet to come
bounding box computation, length measurements... Why not let WebPositive
use agg directly? Would increase security and even integration...
If we were to do this, it would probably be not using agg, but cairo,
which is already supported by WebKit. This would make a lot of things
easier, since the cairo code is used by GTKWebKit and already well-tested
there and in a few other places. However, it has the following
disadvantages:
- The rendering will never look exactly the same as for native apps. By
using the same API, we make sure WebKit renders exactly the same way as
other applications, which is part of the efforts to provide an extremely
consistent look and feel.
- Possibly usage of WebKit through remote_app_server would be faster by
sending only drawing commands to the app_server, but that is probably only
true to some extent (for simple webpages). Now the number of operations is
so high that it probably is slower in the end than just sending a bitmap.
- It proves to be a very good stress test for app_server and interface kit
APIs, and that seems important to me as an OS developer. If we are not
able to deliver these nice complex drawing APIs to native apps, what is
the point in writing all this OS? Surely everyone will write only web apps
because they have more features there, and the native API just isn't good
enough.
I agree that this approach may not be the best in the short term. We don't
get a good working web browser because of it, and if we just used cairo
(and curl for http) to power WebKit, we would have saved a lot of hours
(or even days or months) of work for various people trying to get this to
work.
It kind of worked, the native HTTP API is quite good (but it is undergoing
it's 3rd or 4th rewrite) and app_server is a lot more capable than it was
before we started trying to use it for webkit. So I don't know at which
point we should stop efforts in that direction.
/haiku/src/servers/app/DrawState.cpp : DrawState::PenSize returns at
least 1 (not in screen space). Even in screen pixel space this would make
sense only with antialiasing disabled (no such option in haiku).
There is a B_SUBPIXEL_PRECISE flag on BView to enable full usage of
subpixel coordinates. When this flag is set, this method could return
smaller values. And indeed the screen vs transformed space issues need to
be solved (there are probably more of these)
app_server: Differentiate text and geometry antialiasing generally to
prevent rainbow borders on geometry. Because text is usually small and
pixel-hinted, artifacts are minimal there.
app_server antialiasing works quite well for native apps I think, so I'm
not sure why it looks so bad in WebKit.
The antialiasing on text is also (and mainly) limited by font hinting,
which forces the fonts to be aligned closely on subpixel boundaries. There
is nothing like that for regular drawing. And I think the Appearance
preference to adjust the antialisaing to have more or less colorfringing
also only applies to text.
--
Ticket URL: <
https://dev.haiku-os.org/ticket/17538#comment:6>
Haiku <
https://dev.haiku-os.org>
The Haiku operating system.
Other related posts:
