6:37 a.m.
The existing plotter API has been slowly extended as NetSurf has evolved,
and it's a bit inconsistent.
John-Mark has put a proposal for improving it up here:
http://wiki.netsurf-browser.org/plotter-api
Comments welcome.
Cheers,
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
10:27 a.m.
On Sun, 28 Jun 2009 12:37:32 +0100, Michael Drake wrote:
The existing plotter API has been slowly extended as NetSurf has
evolved, and it's a bit inconsistent.
John-Mark has put a proposal for improving it up here:
http://wiki.netsurf-browser.org/plotter-api
Comments welcome.
|All colours are in the form 0xAABBGGRR.
|On little-endian platforms, bitmaps are also 0xAABBGGRR.
|On big-endian platforms, bitmaps are 0xRRGGBBAA
If we're improving the plotters, can we get this fixed at the same
time? Colours should be in 0xRRGGBBAA on big-endian platforms, same
as the bitmaps.
|bool (*find_font)(void *pw, const char **font_names, size_t n, font_t *result);
Opening and closing fonts here is relatively slow, so I'd like to keep
it to a minimum. Can we assume that find_font should also open the
font in question? How do we find out when NetSurf has finished with
it (for the page)? Some way of keeping track of usage in the platform
code and being able to flush any that have not been used for a while
would be useful here I think.
Regarding generic families, the easiest thing would be for NetSurf to
send the user's selected font for the desired family (from
option_font_sans etc) in the font_names array.
Chris
11:02 a.m.
On Sun, 2009-06-28 at 16:27 +0100, Chris Young wrote:
On Sun, 28 Jun 2009 12:37:32 +0100, Michael Drake wrote:
> The existing plotter API has been slowly extended as NetSurf has
> evolved, and it's a bit inconsistent.
>
> John-Mark has put a proposal for improving it up here:
>
> http://wiki.netsurf-browser.org/plotter-api
>
> Comments welcome.
|All colours are in the form 0xAABBGGRR.
|On little-endian platforms, bitmaps are also 0xAABBGGRR.
|On big-endian platforms, bitmaps are 0xRRGGBBAA
If we're improving the plotters, can we get this fixed at the same
time? Colours should be in 0xRRGGBBAA on big-endian platforms, same
as the bitmaps.
I don't think so. If anything, the bitmaps should match colours. This
way, everything is 0xAABBGGRR on all platforms. I'm aware this component
ordering is rather odd -- it's a legacy thing from NetSurf's RISC OS
origins.
|bool (*find_font)(void *pw, const char **font_names, size_t n,
font_t *result);
Opening and closing fonts here is relatively slow, so I'd like to keep
it to a minimum. Can we assume that find_font should also open the
font in question?
If you want to, yes; it's entirely down to the frontend to make that
decision. The point of this API is to be able to map a CSS font-family
(be that a series of font names or a generic family) to some opaque
handle that identifies it to the plotter.
In many frontends, this will simply scan the provided list of font names
and pick the first that is present on the system.
Note, however, that this API doesn't provide you with information about
font weight, slantedness, or size. If you need that information to open
a font, then you may be stuck.
How do we find out when NetSurf has finished with it (for the page)?
It's guaranteed to be finished with it once the redraw has completed.
It's your choice whether to keep it around for longer.
Some way of keeping track of usage in the platform code and being
able
to flush any that have not been used for a while would be useful here
I think.
Can you not do this with the proposed API? An LRU cache of font
descriptors shouldn't be hard to implement on top of it. You'll want to
base usage on calls to the text plotter with the given font handle as
it's possible that the core redraw stuff will optimise out calling
find_font in cases where it already knows the font handle for some text.
Regarding generic families, the easiest thing would be for NetSurf
to
send the user's selected font for the desired family (from
option_font_sans etc) in the font_names array.
Yes, I'm inclined to agree. The array is sorted as per the original
font-family rule that generated it. For example:
font-family: "Helvetica", "Arial", sans-serif;
would produce an array:
Helvetica
Arial
<option_font_sans>
find_font need only scan as much of the array as needed to find a font
it can use.
J.
noon
On Sun, 28 Jun 2009 17:02:28 +0100, John-Mark Bell wrote:
> |All colours are in the form 0xAABBGGRR.
> |On little-endian platforms, bitmaps are also 0xAABBGGRR.
> |On big-endian platforms, bitmaps are 0xRRGGBBAA
>
> If we're improving the plotters, can we get this fixed at the same
> time? Colours should be in 0xRRGGBBAA on big-endian platforms, same
> as the bitmaps.
I don't think so. If anything, the bitmaps should match colours. This
way, everything is 0xAABBGGRR on all platforms. I'm aware this component
ordering is rather odd -- it's a legacy thing from NetSurf's RISC OS
origins.
The odd ordering causes potential problems here, as most of the Amiga
graphics functions expect RGBA or ARGB (ARGB is more common). If
that's the option then I'd rather it was all left in the current crazy
dual-fashion.
> Some way of keeping track of usage in the platform code and
being able
> to flush any that have not been used for a while would be useful here
> I think.
Can you not do this with the proposed API? An LRU cache of font
descriptors shouldn't be hard to implement on top of it. You'll want to
base usage on calls to the text plotter with the given font handle as
it's possible that the core redraw stuff will optimise out calling
find_font in cases where it already knows the font handle for some text.
Yes, should be able to. If the core is guaranteed to forget what
find_fonts has allocated (ie. it won't reuse it on subsequent redraws
even if redrawing part of the same page), then there is no problem.
If the core will cache the result of find_fonts and use it in
subsequent redraws, the platform code will need to know when it has
finished with it.
That's really more what I was getting at.
Regards
Chris
12:10 p.m.
On Sun, 2009-06-28 at 18:00 +0100, Chris Young wrote:
On Sun, 28 Jun 2009 17:02:28 +0100, John-Mark Bell wrote:
> > |All colours are in the form 0xAABBGGRR.
> > |On little-endian platforms, bitmaps are also 0xAABBGGRR.
> > |On big-endian platforms, bitmaps are 0xRRGGBBAA
> >
> > If we're improving the plotters, can we get this fixed at the same
> > time? Colours should be in 0xRRGGBBAA on big-endian platforms, same
> > as the bitmaps.
>
> I don't think so. If anything, the bitmaps should match colours. This
> way, everything is 0xAABBGGRR on all platforms. I'm aware this component
> ordering is rather odd -- it's a legacy thing from NetSurf's RISC OS
> origins.
The odd ordering causes potential problems here, as most of the Amiga
graphics functions expect RGBA or ARGB (ARGB is more common). If
that's the option then I'd rather it was all left in the current crazy
dual-fashion.
Ugh. Ok.
> > Some way of keeping track of usage in the platform code and
being able
> > to flush any that have not been used for a while would be useful here
> > I think.
>
> Can you not do this with the proposed API? An LRU cache of font
> descriptors shouldn't be hard to implement on top of it. You'll want to
> base usage on calls to the text plotter with the given font handle as
> it's possible that the core redraw stuff will optimise out calling
> find_font in cases where it already knows the font handle for some text.
Yes, should be able to. If the core is guaranteed to forget what
find_fonts has allocated (ie. it won't reuse it on subsequent redraws
even if redrawing part of the same page), then there is no problem.
If the core will cache the result of find_fonts and use it in
subsequent redraws, the platform code will need to know when it has
finished with it.
I think it's unlikely that the core will cache that information across
redraws. In fact, it simply can't -- the reason find_font is a plotter
callback is that it depends on the output device, not the frontend.
J.
2:46 p.m.
Hello
On 28.06.09, you wrote:
Note, however, that this API doesn't provide you with information
about
font weight, slantedness, or size. If you need that information to open
a font, then you may be stuck.
I do some profiling on netsurf, the open font seem cost not much speed when
the
font was open before.freetype use a cache.maybe it can happen when use lots
fonts, that this cache get too small. but there is a command in freetype to
set the cache size.
But what cost much speed and also depend on memory system get fragment
slowdown, is that netsurf on libxml and somewhere else do very often malloc
and free calls.
i guess near 15% of overall time netsurf stay in malloc and free calls.the
good news is that netsurf use very few stack.I notice only 30 kb stack
usage.but is there a way to replace some frequently malloc/ free with
malloc on stack ?
On amiga 68k OS there are memtrackers for developing (that add bounds around
each memblock, normaly it slow down a program by about 50%.
But when run netsurf it slowdown a program by about Factor 10.and i use a
AMD64 3000+ with a memtransfer speed of 800 megabytes with the amiga
emulator.
It is near impossible to show a page in usefull time when memtracker is on.
but recommend to develop programs is use memtracker that do boundcheck on
every free command and fill the freed blocks to see soon code that access a
freed block.
> How do we find out when NetSurf has finished with it (for the page)?
It's guaranteed to be finished with it once the redraw has completed.
It's your choice whether to keep it around for longer.
> Some way of keeping track of usage in the platform code and being able
> to flush any that have not been used for a while would be useful here
> I think.
Can you not do this with the proposed API? An LRU cache of font
descriptors shouldn't be hard to implement on top of it. You'll want to
base usage on calls to the text plotter with the given font handle as
it's possible that the core redraw stuff will optimise out calling
find_font in cases where it already knows the font handle for some text.
> Regarding generic families, the easiest thing would be for NetSurf to
> send the user's selected font for the desired family (from
> option_font_sans etc) in the font_names array.
Yes, I'm inclined to agree. The array is sorted as per the original
font-family rule that generated it. For example:
font-family: "Helvetica", "Arial", sans-serif;
would produce an array:
Helvetica
Arial
<option_font_sans>
find_font need only scan as much of the array as needed to find a font
it can use.
J.
Regards
4:20 a.m.
In article
<OUT-4A47AFD6.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
The odd ordering causes potential problems here, as most of the
Amiga
graphics functions expect RGBA or ARGB (ARGB is more common). If
that's the option then I'd rather it was all left in the current crazy
dual-fashion.
The advantage of keeping it all in one format is it will simplify stuff
where the core modifies images, e.g. via scripting. But I guess that can
be worked around.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
4:21 a.m.
From: netsurf-dev-bounces(a)netsurf-browser.org
[mailto:netsurf-dev-bounces@netsurf-browser.org] On Behalf Of
Michael Drake
The existing plotter API has been slowly extended as NetSurf
has evolved, and it's a bit inconsistent.
John-Mark has put a proposal for improving it up here:
http://wiki.netsurf-browser.org/plotter-api
This all looks nicer to me, although I'd like to extend the API slightly to
simplify more complex plotters. The first change I'd like to forward is
simply:
bool (*initialise)(void *pw); /** <optional, may be NULL */
bool (*finalise)(void *pw); /** <optional, may be NULL */
These would be called upon the plotters being changed, and would allow for
any memory required by the plotters (knockout renderer's buffers etc) or
caching (LUTs for font matching?) to be cleanly handled.
The second change is to extend the bitmap API slightly to support the CSS3
image-orientation tag (http://www.w3.org/TR/css3-page/#orienting) I'd
suggest that the simplest manner to support this is to just add an extra
parameter to both bitmap and bitmap_tile.
bool (*bitmap)(void *pw, const plot_rect *rect, struct bitmap *bitmap,
colour_t bg_colour, float orientation);
bool (*bitmap_tile)(void *pw, const plot_rect *rect, struct bitmap *bitmap,
colour_t bg_colour, float orientation, bool repeat_x, bool repeat_y);
Regarding the merging of these two functions -- I'm in two minds. On the
positive side, it would give simpler code paths to follow, but on the
negative, it would add a bunch of pointless parameters to all non-background
image code. I'd possibly like to merge repeat_x and repeat_y into a flag
word too...
Comments?
R.
--
Richard Wilson
7:35 a.m.
On Mon, 2009-06-29 at 10:21 +0100, Richard Wilson wrote:
> From: netsurf-dev-bounces(a)netsurf-browser.org
> [mailto:netsurf-dev-bounces@netsurf-browser.org] On Behalf Of
> Michael Drake
>
> The existing plotter API has been slowly extended as NetSurf
> has evolved, and it's a bit inconsistent.
>
> John-Mark has put a proposal for improving it up here:
>
> http://wiki.netsurf-browser.org/plotter-api
This all looks nicer to me, although I'd like to extend the API slightly to
simplify more complex plotters. The first change I'd like to forward is
simply:
bool (*initialise)(void *pw); /** <optional, may be NULL */
bool (*finalise)(void *pw); /** <optional, may be NULL */
These would be called upon the plotters being changed, and would allow for
any memory required by the plotters (knockout renderer's buffers etc) or
caching (LUTs for font matching?) to be cleanly handled.
Adrian had independently suggested the same to me :) I've made this
change.
The second change is to extend the bitmap API slightly to support
the CSS3
image-orientation tag (http://www.w3.org/TR/css3-page/#orienting) I'd
suggest that the simplest manner to support this is to just add an extra
parameter to both bitmap and bitmap_tile.
bool (*bitmap)(void *pw, const plot_rect *rect, struct bitmap *bitmap,
colour_t bg_colour, float orientation);
bool (*bitmap_tile)(void *pw, const plot_rect *rect, struct bitmap *bitmap,
colour_t bg_colour, float orientation, bool repeat_x, bool repeat_y);
I wonder if the orientation can be sorted out in the core. Thus bitmaps
presented to the plotters are always oriented correctly.
Regarding the merging of these two functions -- I'm in two
minds. On the
positive side, it would give simpler code paths to follow, but on the
negative, it would add a bunch of pointless parameters to all non-background
image code. I'd possibly like to merge repeat_x and repeat_y into a flag
word too...
Yeah, I'm not entirely convinced about merging them, either. The GTK
tiled plotter, for example, does much the same a Tinct when plotting
tiled bitmaps -- expand small images to something larger and then tile
that for performance. I can see that being complicated by only having
one entry point.
J.
7:45 a.m.
On Mon, 2009-06-29 at 10:20 +0100, Michael Drake wrote:
In article
<OUT-4A47AFD6.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
> The odd ordering causes potential problems here, as most of the Amiga
> graphics functions expect RGBA or ARGB (ARGB is more common). If
> that's the option then I'd rather it was all left in the current crazy
> dual-fashion.
The advantage of keeping it all in one format is it will simplify stuff
where the core modifies images, e.g. via scripting. But I guess that can
be worked around.
The most obvious solution to all of this is to make bitmaps completely
opaque to the core and have them provide accessors/mutators for bitmap
data in a defined format (namely: whatever the core speaks). The
frontend can then store bitmap data in whatever format they like and the
core can still access it as necessary.
I know Vince has been planning some other bitmap-related changes, so I'm
not sure if the above suggestion is compatible with his thinking.
However, at this stage, I'd rather preserve the status quo until we've
got the myriad streams of development merged back onto trunk. On the
upside, this gives us lots of thinking time :)
J.
8:17 a.m.
In article <1246279542.18148.312.camel@duiker>,
John-Mark Bell <jmb(a)netsurf-browser.org> wrote:
The most obvious solution to all of this is to make bitmaps
completely
opaque to the core and have them provide accessors/mutators for bitmap
data in a defined format (namely: whatever the core speaks). The
frontend can then store bitmap data in whatever format they like and the
core can still access it as necessary.
I think it's then harder to have the image decoders in the core, isn't it?
Every platform would need their own implementation.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
8:33 a.m.
On Mon, 2009-06-29 at 14:17 +0100, Michael Drake wrote:
In article <1246279542.18148.312.camel@duiker>,
John-Mark Bell <jmb(a)netsurf-browser.org> wrote:
> The most obvious solution to all of this is to make bitmaps completely
> opaque to the core and have them provide accessors/mutators for bitmap
> data in a defined format (namely: whatever the core speaks). The
> frontend can then store bitmap data in whatever format they like and the
> core can still access it as necessary.
I think it's then harder to have the image decoders in the core, isn't it?
Every platform would need their own implementation.
No. That's the wholepoint of providing mechanisms to allow the core to
read/write the image data *in a defined format*.
J.
8:41 a.m.
[mailto:netsurf-dev-bounces@netsurf-browser.org] On Behalf Of
John-Mark Bell
On Mon, 2009-06-29 at 10:21 +0100, Richard Wilson wrote:
<snip>
> The second change is to extend the bitmap API slightly to
support the
> CSS3 image-orientation tag
(http://www.w3.org/TR/css3-page/#orienting)
> I'd suggest that the simplest manner to support this is to
just add an
> extra parameter to both bitmap and bitmap_tile.
>
> bool (*bitmap)(void *pw, const plot_rect *rect, struct
bitmap *bitmap,
> colour_t bg_colour, float orientation); bool
(*bitmap_tile)(void *pw,
> const plot_rect *rect, struct bitmap *bitmap, colour_t bg_colour,
> float orientation, bool repeat_x, bool repeat_y);
I wonder if the orientation can be sorted out in the core.
Thus bitmaps presented to the plotters are always oriented correctly.
The specification states (http://www.w3.org/TR/css3-page/#orienting,
section 7) "In terms of the order of transformations, the image is first
rotated, then sized, then positioned." If I've interpretted this correctly
it means that if you had a 45 degree rotated background image of Soulja Boy
tiled across your MySpace page, it would show the background through:
/\../\../\ < rotate, plot /\**/\**/\
**\/**\/** probably correct **\/**\/**
**/\**/\** **/\**/\**
\/..\/..\/ plot rotated > \/**\/**\
/\../\../\ more Soulja Boy /\**/\**/\
**\/**\/** but wrong **\/**\/**
This means that it really doesn't matter where you do the rotation as the
plotters don't need the additional pattern-repeat information. My desire
would be to have everthing ordered along the lines of:
1) Plotters get passed rotation
2) If plotter can hand rotation, plot rotated natively
3) If plotter can't handle rotation directly, call bitmap_rotate to get a
(cached?) rotated bitmap back which can then be plotted natively
This gives us the best of both worlds (I'm unlikely to ever implement
rotated plotting in Tinct, but would possibly implement Tinct_Rotate to go
in bitmap_rotate to quickly generate the rotated images.)
R.
--
Richard Wilson
10:10 a.m.
On Mon, 2009-06-29 at 14:41 +0100, Richard Wilson wrote:
> [mailto:netsurf-dev-bounces@netsurf-browser.org] On Behalf Of
> John-Mark Bell
> On Mon, 2009-06-29 at 10:21 +0100, Richard Wilson wrote:
<snip>
> > The second change is to extend the bitmap API slightly to
> support the
> > CSS3 image-orientation tag
> (http://www.w3.org/TR/css3-page/#orienting)
> > I'd suggest that the simplest manner to support this is to
> just add an
> > extra parameter to both bitmap and bitmap_tile.
> >
> > bool (*bitmap)(void *pw, const plot_rect *rect, struct
> bitmap *bitmap,
> > colour_t bg_colour, float orientation); bool
> (*bitmap_tile)(void *pw,
> > const plot_rect *rect, struct bitmap *bitmap, colour_t bg_colour,
> > float orientation, bool repeat_x, bool repeat_y);
>
> I wonder if the orientation can be sorted out in the core.
> Thus bitmaps presented to the plotters are always oriented correctly.
The specification states (http://www.w3.org/TR/css3-page/#orienting,
section 7) "In terms of the order of transformations, the image is first
rotated, then sized, then positioned." If I've interpretted this correctly
it means that if you had a 45 degree rotated background image of Soulja Boy
tiled across your MySpace page, it would show the background through:
/\../\../\ < rotate, plot /\**/\**/\
**\/**\/** probably correct **\/**\/**
**/\**/\** **/\**/\**
\/..\/..\/ plot rotated > \/**\/**\
/\../\../\ more Soulja Boy /\**/\**/\
**\/**\/** but wrong **\/**\/**
Surely that entirely depends upon how you advance the x/y coordinates
when tiling?
Consider:
___
| |
|___|
Rotate 45 degrees:
/\
/ \
\ /
\/
Now, given that everything plots rectangles you'd have a rotated bitmap,
thus:
------
|./\.|
|/ \|
|\ /|
|.\/.|
------
With the '.'s being transparent.
To get your first background, you'd tile this larger, rotated image,
advancing x/y to the bounds of the larger bitmap.
I'm struggling to see how you'd achieve your second background in a
generic way. It's certainly possible to tesselate some rotated images in
the way you suggest, but non-square, non-multiple-of-45-degree rotations
won't.
However, I think this is all moot. The current draft of the
specification makes it clear that image-orientation can only be a
multiple of 90 degrees and is applied as a one-off transform to the
source image data: http://dev.w3.org/csswg/css3-page/#image-orientation
That said, CSS3 does have modules for 2D and 3D transforms. The former
is the standard 2d transform matrix. The latter, I've not investigated.
At some point in the future, therefore, we will need a solution that
permits transformed rendering of everything. I'm not inclined to start
considering this in detail now, though. It may well be that we end up
feeding the current transformation matrix to the plotters. Note that
transforms can affect layout, however, so they're somewhat complicated.
This gives us the best of both worlds (I'm unlikely to ever
implement
rotated plotting in Tinct, but would possibly implement Tinct_Rotate to go
in bitmap_rotate to quickly generate the rotated images.)
Talking of Tinct; can you stick the sources in SVN, please? :)
J.
5017
days inactive
5018
days old
netsurf-dev@netsurf-browser.org
13 comments
5 participants
participants (5)
-
Bernd Roesch -
Chris Young -
John-Mark Bell -
Michael Drake -
Richard Wilson