7:55 p.m.
Hi,
I mentioned on IRC that lh had pre-announced this year's GSoC -- the
official announcement, with details, will be at FOSDEM. The timetable
is likely to be similar to last year's.
Some questions:
1. Are we intending to apply this year?
2. What projects do we have that can be done over a summer?
3. What should our student application process be?
4. Who is available to mentor?
(That's enough questions, Ed.)
J.
9:47 p.m.
In article <Pine.LNX.4.64.0901141851380.25847(a)login.ecs.soton.ac.uk>,
John-Mark Bell <jmb(a)netsurf-browser.org> wrote:
Some questions:
1. Are we intending to apply this year?
Yes, I think it's certainly worth it. :)
2. What projects do we have that can be done over a summer?
FWIW, last years list was:
1. New CSS parser and selector engine
2. Native Windows or Mac OS X ports
3. Keyboard navigation
4. Printing improvements
5. PDF plotter
6. Page reader
7. Dynamic pseudo classes
8. Abstract RISC OS GUI code into a separate library
9. Extracting the core into a library
10. Improved inline element handling
11. Improved GTK front end; tabs, downloads, etc
1. Is currently in progress, as libcss. Dunno what the changes are it
will be done by the time GSoC starts.
4. & 5. Could probably do with some more polishing, but I'm not sure it's
worth a summer project.
7. Depends on libcss.
9. Is currently partially done. We would need to assess exactly how
much more is needed for this.
10. The changes to make rendering take into account margins, paddings,
splittings and nestings when plotting background colours, images
and borders are done. There are still other issues like white-space
property and vertical-align.
11. Obviously this was improved significantly over the last GSoC, but
I think an improving the GTK front end project could be run again.
The rest (2, 3, 6 and 8) can all be run again, as those aspects haven't
been touched.
Also, we can think up new projects. I'll have a think about that for a few
days.
3. What should our student application process be?
Same as last time? Maybe we should do more to encourage patches before
student application deadline.
4. Who is available to mentor?
I am available to be a mentor candidate. I think it worked quite well last
time, when I was available to help any student when other mentors weren't
around, although I think I could be a mentor for something layout or box
tree related.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
11:01 p.m.
On Wed, 14 Jan 2009, Michael Drake wrote:
[CSS parser]
1. Is currently in progress, as libcss. Dunno what the changes
are it
will be done by the time GSoC starts.
Even if it isn't, there's not enough work left to fill 10 weeks. The
selection algorithm can easily be implemented in a few days of full-time
resource, and that's the only major thing outstanding. The remaining
parsing issues are trivial in comparison.
[PDF export & printing]
4. & 5. Could probably do with some more polishing, but I'm
not sure it's
worth a summer project.
Agreed.
[Dynamic pseudo classes]
7. Depends on libcss.
Likely. It's mostly layout, however.
[fandango]
9. Is currently partially done. We would need to assess exactly
how
much more is needed for this.
Sean? Can you comment on this?
[Inlines]
10. The changes to make rendering take into account margins,
paddings,
splittings and nestings when plotting background colours, images
and borders are done. There are still other issues like white-space
property and vertical-align.
Right.
[GTK frontend]
11. Obviously this was improved significantly over the last GSoC,
but
I think an improving the GTK front end project could be run again.
[Keyboard nav, other platforms, page reader, RO gui code -> library]
The rest (2, 3, 6 and 8) can all be run again, as those aspects
haven't
been touched.
The first three seem reasonable. I have serious reservations about
a) finding someone suitably qualified and b) the utility of extracting a
library from the RO UI code.
Also, we can think up new projects. I'll have a think about that
for a few
days.
One that is obvious to me is libdom. It needs the following doing to it:
1) Fixing so it compiles
2) Sort out the mess that is dom_string
3) Use vtables rather than known function names + switching on node type
4) Test suite
5) Write a binding to hubbub
6) The rest of DOM 3/2/1/0 implementing (primarily, Events)
> 3. What should our student application process be?
Same as last time? Maybe we should do more to encourage patches before
student application deadline.
Here's my comments from last year:
In future, it would be useful to specify our application requirements
more clearly. I don't think it's worthwhile to provide a template, as
that makes things too easy. The idea here is to provide sufficient
hurdles to weed out the majority of poor applications. We could also
require some code contribution prior to application.
In addition to that, any student who suggests their own idea gets a thumbs
up from me. Not least as this implies that they've actually thought about
it. Similarly, anyone who interacts with us well from an early stage is
probably more likely to be favoured.
> 4. Who is available to mentor?
I expect I am.
J.
12:05 a.m.
In article <Pine.LNX.4.64.0901142139190.2171(a)login.ecs.soton.ac.uk>,
John-Mark Bell <jmb(a)netsurf-browser.org> wrote:
On Wed, 14 Jan 2009, Michael Drake wrote:
[CSS parser]
Even if it isn't, there's not enough work left to fill 10
weeks. The
selection algorithm can easily be implemented in a few days of full-time
resource, and that's the only major thing outstanding. The remaining
parsing issues are trivial in comparison.
OK. Although, IIRC GSoC wanted organisations to have ideas with a broad
range of difficulties and if a student finishes whatever project they
undertook early, I'm sure we could come up with some other stuff that both
the student and mentor would be interested in. :)
As for libcss, won't integrating with NetSurf be a bit non-trivial?
[Dynamic pseudo classes]
> 7. Depends on libcss.draw.
Likely. It's mostly layout, however.
Yep, we'd need some way for the core to know which bits of layout would be
affected, run layout on those bits and then redraw. I think partial layout
could take a fair bit of thinking about.
[Inlines]
> 10. The changes to make rendering take into account margins, paddings,
> splittings and nestings when plotting background colours, images
> and borders are done. There are still other issues like white-space
> property and vertical-align.
Right.
Line heights are also fixed since then. The unicode line splitting thing
mentioned on the old ideas page is not relevant, I think. It's a RUfl
issue, I think, because that stuff works on the GTK port. James?
[Keyboard nav, other platforms, page reader, RO gui code ->
library]
> The rest (2, 3, 6 and 8) can all be run again, as those aspects haven't
> been touched.
The first three seem reasonable. I have serious reservations about
a) finding someone suitably qualified and b) the utility of extracting a
library from the RO UI code.
Well a) shouldn't be a concern for us. Perhaps you're right for b),
although I think it might be nice. Maybe we could have an idea about doing
RO GUI work like tabs.
> Also, we can think up new projects. I'll have a think about
that for a
> few days.
One that is obvious to me is libdom. It needs the following doing to
it:
1) Fixing so it compiles
2) Sort out the mess that is dom_string
3) Use vtables rather than known function names + switching on node type
4) Test suite
5) Write a binding to hubbub
6) The rest of DOM 3/2/1/0 implementing (primarily, Events)
Cool. I guess it's a bit early for discussing details, but maybe 1) should
be done before GSoCage.
The idea that leaps out at me is a layout and box tree test system and
test suite. It would be ideal if we already had a separated layout engine,
but I guess something could be done like making a minimal NetSurf front
end and working off that. IIRC, there's a framebuffer front end which
doesn't do any framebuffer stuff. The tester could work by dumping layout
stuff like box tree with sizes and position details and matching with a
test suite.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
1:11 a.m.
On Wed, 14 Jan 2009, Michael Drake wrote:
In article
<Pine.LNX.4.64.0901142139190.2171(a)login.ecs.soton.ac.uk>,
John-Mark Bell <jmb(a)netsurf-browser.org> wrote:
> On Wed, 14 Jan 2009, Michael Drake wrote:
> [CSS parser]
> Even if it isn't, there's not enough work left to fill 10 weeks. The
> selection algorithm can easily be implemented in a few days of full-time
> resource, and that's the only major thing outstanding. The remaining
> parsing issues are trivial in comparison.
OK. Although, IIRC GSoC wanted organisations to have ideas with a broad
range of difficulties and if a student finishes whatever project they
undertook early, I'm sure we could come up with some other stuff that both
the student and mentor would be interested in. :)
Er. There's 5 months between now and the start of GSoC coding. Therefore,
I'd have to not touch libcss again for there to be any chance of it being
a GSoC project.
As for libcss, won't integrating with NetSurf be a bit
non-trivial?
I doubt it -- it's mostly search and replace. Anyway, in the first
instance, I'd just graft libcss' output onto what NetSurf's layout engine
expects. Everything's going to have to be modified to support dynamic
document/style changes, anyway. There's also the new DOM to consider.
> [Dynamic pseudo classes]
>> 7. Depends on libcss.draw.
> Likely. It's mostly layout, however.
Yep, we'd need some way for the core to know which bits of layout would be
affected, run layout on those bits and then redraw. I think partial layout
could take a fair bit of thinking about.
My intention was for it to be entirely event based, even for the initial
layout. If I get some time, I'll write it down.
> [Inlines]
>> 10. The changes to make rendering take into account margins, paddings,
>> splittings and nestings when plotting background colours, images
>> and borders are done. There are still other issues like white-space
>> property and vertical-align.
> Right.
Line heights are also fixed since then. The unicode line splitting thing
mentioned on the old ideas page is not relevant, I think. It's a RUfl
issue, I think, because that stuff works on the GTK port. James?
Yes, it's a RUfl thing -- it has no knowledge of how to do linebreaking
properly (just splits on the nearest whitespace).
> [Keyboard nav, other platforms, page reader, RO gui code ->
library]
>> The rest (2, 3, 6 and 8) can all be run again, as those aspects haven't
>> been touched.
> The first three seem reasonable. I have serious reservations about
> a) finding someone suitably qualified and b) the utility of extracting a
> library from the RO UI code.
Well a) shouldn't be a concern for us. Perhaps you're right for b),
although I think it might be nice. Maybe we could have an idea about doing
RO GUI work like tabs.
Still doesn't deal with (a) :P
>> Also, we can think up new projects. I'll have a think
about that for a
>> few days.
> One that is obvious to me is libdom. It needs the following doing to it:
> 1) Fixing so it compiles
> 2) Sort out the mess that is dom_string
> 3) Use vtables rather than known function names + switching on node type
> 4) Test suite
> 5) Write a binding to hubbub
> 6) The rest of DOM 3/2/1/0 implementing (primarily, Events)
Cool. I guess it's a bit early for discussing details, but maybe 1) should
be done before GSoCage.
It's trivial -- the current (partial) hubbub binding is broken.
The idea that leaps out at me is a layout and box tree test system
and
test suite. It would be ideal if we already had a separated layout engine,
but I guess something could be done like making a minimal NetSurf front
end and working off that. IIRC, there's a framebuffer front end which
doesn't do any framebuffer stuff. The tester could work by dumping layout
stuff like box tree with sizes and position details and matching with a
test suite.
Yes. Building such a testsuite is decidedly non-trivial :)
I've put last year's organisation application form on the wiki:
http://wiki.netsurf-browser.org/gsoc-org-app
J.
9:01 p.m.
So the possible ideas so far are:
1. Native Windows or Mac OS X ports
2. Keyboard navigation
3. Page reader
4. Extracting the core into a library
5. Layout engine improvements
6. LibDOM
7. LibSVGTiny
8. Automated NetSurf layout test suite
9. Improved GTK front end
10. Improved Haiku/BeOS front end
11. Improved RISC OS front end
It would be good to have some more core related ones, I think. How about
that idea that's popped up a few times about allowing NetSsurf to make a
report of all errors and problems found with the HTML and CSS of a page
and the rewrite of NetSurf's internal logging handling?
Also how about an idea related to general browsing efficiency, for example
only decoding images when they need to be displayed, making a disc cache,
and other stuff? Don't know how much work there is in that kind of thing.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
12:19 a.m.
On Tue, 27 Jan 2009 20:01:36 +0000 (GMT), Michael Drake wrote:
2. Keyboard navigation
Is there any form of keyboard navigation already (bar tabbing between
input boxes)? One site I visit I find I can't type the letter R
anywhere, and I decided NetSurf must be soaking it up due to it being
a keyboard shortcut within the HTML.
Also how about an idea related to general browsing efficiency, for
example
only decoding images when they need to be displayed, making a disc cache,
and other stuff? Don't know how much work there is in that kind of thing.
General rendering optimisations would be very good. I get sluggish
scrolling on some sites, and although I think it is mostly down to
alpha blitting of images (which is far slower than it ought to be), it
can be a bit slow in other instances too. For some reason typing
characters in an input box in one of these slow areas is painful -
maybe NetSurf is redrawing too much of the page? I'm sure something
could be done in this area given enough time to analyse it.
Chris
12:16 a.m.
In article
<OUT-497F967E.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
On Tue, 27 Jan 2009 20:01:36 +0000 (GMT), Michael Drake wrote:
> 2. Keyboard navigation
Is there any form of keyboard navigation already (bar tabbing
between
input boxes)? One site I visit I find I can't type the letter R
anywhere, and I decided NetSurf must be soaking it up due to it being
a keyboard shortcut within the HTML.
No, there is no keyboard navigation other than tabbing between form
elements. Typing 'R' should certainly work on every site, e.g in forms and
stuff.
I get sluggish scrolling on some sites,
Which sites? Scrolling speed is fast here and doesn't vary between sites.
and although I think it is mostly down to alpha blitting of images
(which is far slower than it ought to be), it can be a bit slow in other
instances too. For some reason typing characters in an input box in one
of these slow areas is painful - maybe NetSurf is redrawing too much of
the page?
It should only redraw the relevant bit. Which pages have this problem? I
haven't seen this issue here.
Have you tried turning knockout rendering on/off and seeing if it makes a
difference?
Cheers,
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
1:22 a.m.
On Thu, 29 Jan 2009 23:16:38 +0000 (GMT), Michael Drake wrote:
No, there is no keyboard navigation other than tabbing between form
elements. Typing 'R' should certainly work on every site, e.g in forms and
stuff.
Thanks for confirming that - I've just realised why. If the website
title has an underline in it, when you put this text into a gadget
label, that underline means the next character becomes a keyboard
shortcut. If, for example, you try to write a reply in a thread
called something involving WA_RMBTrap, all attempts to type the letter
R result in the current tab being reselected and nothing much else.
Oops. I shall obviously be fixing this.
> I get sluggish scrolling on some sites,
Which sites? Scrolling speed is fast here and doesn't vary between sites.
Mostly ones with complicated amounts of imagery - eg.
http://www.bbc.co.uk is really slow.
> and although I think it is mostly down to alpha blitting of
images
> (which is far slower than it ought to be), it can be a bit slow in other
> instances too. For some reason typing characters in an input box in one
> of these slow areas is painful - maybe NetSurf is redrawing too much of
> the page?
It should only redraw the relevant bit. Which pages have this problem? I
haven't seen this issue here.
Try the site I was having fun with typing R on -
http://www.utilitybase.com
This isn't the worst example, but typing anything into the search box
is slower than it should be. Typing into Google's search box is the
speed it should be.
My gui_window_redraw redraws the entire page, and
gui_window_redraw_box draws immediately rather than offloading to the
next refresh, which could be causing an issue.
I'm still not entirely convinced I'm feeding the right values into
content_redraw, so it may may well be a local implementation problem.
Have you tried turning knockout rendering on/off and seeing if it
makes a
difference?
I keep toggling that thing back and forth and can never tell the
difference! I've just tried again, paying particular attention to
typing and scrolling, and it seems marginally quicker on the setting I
had it on originally: true.
Chris
1:31 a.m.
On 30 Jan 2009 00:22:55 +0000, Chris Young wrote:
This isn't the worst example, but typing anything into the search
box
is slower than it should be. Typing into Google's search box is the
speed it should be.
This is a slower one "enter product model" box - if I scroll the page
so the text input box is right at the top of the display, entry is
nice and fast, which seems to confirm that it is redrawing bits of the
page that it shouldn't.
http://www.sony.co.uk/section/support
Regards
Chris
3:06 p.m.
In article
<OUT-4982485F.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
Mostly ones with complicated amounts of imagery - eg.
http://www.bbc.co.uk is really slow.
There's no slowdown there here.
> > and although I think it is mostly down to alpha blitting of
images
> > (which is far slower than it ought to be), it can be a bit slow in
> > other instances too. For some reason typing characters in an input
> > box in one of these slow areas is painful - maybe NetSurf is
> > redrawing too much of the page?
>
> It should only redraw the relevant bit. Which pages have this problem?
> I haven't seen this issue here.
Try the site I was having fun with typing R on -
http://www.utilitybase.com
This isn't the worst example, but typing anything into the search
box
is slower than it should be. Typing into Google's search box is the
speed it should be.
That site is just as fast as Google or anywhere else for typing in the
form. Same with that Sony URL.
My gui_window_redraw redraws the entire page, and
gui_window_redraw_box draws immediately rather than offloading to the
next refresh, which could be causing an issue.
Yeah, I guess there's probably something wrong there, although I don't
know too much about that code. Anyone else know?
I'm still not entirely convinced I'm feeding the right values
into
content_redraw, so it may may well be a local implementation problem.
OK.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
3:07 p.m.
On Fri, 2009-01-30 at 14:06 +0000, Michael Drake wrote:
In article
<OUT-4982485F.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
> My gui_window_redraw redraws the entire page, and
> gui_window_redraw_box draws immediately rather than offloading to the
> next refresh, which could be causing an issue.
Yeah, I guess there's probably something wrong there, although I don't
know too much about that code. Anyone else know?
Sounds like the entire page is being redrawn all the time, rather than
just the box containing the text field. I can't immediately think of a
reason why gui_window_redraw_box couldn't draw immediately.
> I'm still not entirely convinced I'm feeding the right
values into
> content_redraw, so it may may well be a local implementation problem.
Certainly, ensuring you've got the correct clip rectangle is pretty
important from the perspective of ensuring rapid redraw.
J.
8:57 p.m.
On Fri, 30 Jan 2009 14:07:56 +0000, John-Mark Bell wrote:
Sounds like the entire page is being redrawn all the time, rather
than
just the box containing the text field.
Looking back at the code, and where I got it from, I think you're
right.
> > I'm still not entirely convinced I'm feeding the
right values into
> > content_redraw, so it may may well be a local implementation problem.
Certainly, ensuring you've got the correct clip rectangle is pretty
important from the perspective of ensuring rapid redraw.
content_redraw makes me very confused, and there doesn't seem to be
any documentation on it. Furthermore, my values always appear to be
"inverted" compared to eg the RISC OS implementation (the first four
and the second four coordinates are swapped, otherwise I get no output
or the wrong output).
Please can somebody explain simply what values I'm supposed to be
taking from content_msg_data *data, and where they are supposed to go
in content_redraw. I also have a scroll value which needs to be
deducted from somewhere.
I put in what I think is right and the results are never what I
expect!
Thanks
Chris
11:55 p.m.
In article
<OUT-49835BBA.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
content_redraw makes me very confused, and there doesn't seem to
be
any documentation on it. Furthermore, my values always appear to be
"inverted" compared to eg the RISC OS implementation (the first four
and the second four coordinates are swapped, otherwise I get no output
or the wrong output).
I asked jmb, adrianl and joty about it and have come up with:
--------------------------------------------------------------------------
struct os_box {
int x0;
int y0;
int x1;
iny y1;
};
struct wimp_draw {
wimp_w w;
os_box box;
int xscroll;
int yscroll;
os_box clip;
};
os_box box - The 'visible work area', the portion of window contents
that's shown.
os_box clip - The region to be redrawn
xscroll - How far the window is scrolled down
yscroll - How far the window is scrolled left
| NOTE: For an os_box:
| - (x0, y0) is bottom left
| - (x1, y1) is top right
| - coordinate origin at bottom left of screen,
| +ve y upwards, +ve x right
| - units are 2 per px
|
| However in NetSurf:
| - (x0, y0) is top left
| - (x1, y1) is bottom right
| - coordinate origin at top left of page,
| +ve y downwards, +ve x right
| - units are px
So in riscos/window.c, ro_gui_window_redraw:
ro_plot_origin_x = redraw->box.x0 - redraw->xscroll;
ro_plot_origin_y = redraw->box.y1 - redraw->yscroll;
Gets the coordinates of the top left of the area of the page/canvas
which is at the top left of the visible area.
clip_x0 = (redraw->clip.x0 - ro_plot_origin_x) / 2;
clip_y0 = (ro_plot_origin_y - redraw->clip.y1) / 2;
clip_x1 = (redraw->clip.x1 - ro_plot_origin_x) / 2;
clip_y1 = (ro_plot_origin_y - redraw->clip.y0) / 2;
Gets the area of the page/canvas requested for redraw in NetSurf units,
from top left of visible content display area:
left: clip_x0
top: clip_y0
right: clip_x1
bottom: clip_y1
These are used to call
plot.clip(clip_x0, clip_y0, clip_x1, clip_y1);
which sets up the clip rectangle for the plotters, and
content_redraw(c, 0, 0,
c->width * scale, c->height * scale,
clip_x0, clip_y0, clip_x1, clip_y1,
g->bw->scale,
0xFFFFFF);
the arguments to which are:
c content of type CONTENT_HTML
x coordinate for top-left of redraw
y coordinate for top-left of redraw
width width
height height
clip_x0 clip rectangle
clip_y0 clip rectangle
clip_x1 clip rectangle
clip_y1 clip rectangle
scale scale for redraw
background_colour the background colour
The 'while(more)' thing is because the RISC OS Wimp gives one
rectangle at a time to have redrawn and you need to check for more
rectangles until there are none.
--------------------------------------------------------------------------
Does that help at all? Are there other bits which are uninteligable?
Cheers,
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
midnight
On Sun, 01 Feb 2009 22:55:44 +0000 (GMT), Michael Drake wrote:
Does that help at all? Are there other bits which are uninteligable?
That looks like exactly what I need. I was playing around with
content_redraw again today and got something which appears to work
through trial/error. I will double-check it against that and make
sure it is 100% correct.
Thanks
Chris
1:07 a.m.
In article
<OUT-498629AB.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
On Sun, 01 Feb 2009 22:55:44 +0000 (GMT), Michael Drake wrote:
I will double-check it against that and make sure it is 100% correct.
I just commented what the RISC OS front end does in r6348, which puts it
more succinctly:
http://source.netsurf-browser.org/trunk/netsurf/riscos/window.c?r1=6348&a...
Best regards,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
12:06 p.m.
In article
<OUT-498629AB.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
On Sun, 01 Feb 2009 22:55:44 +0000 (GMT), Michael Drake wrote:
That looks like exactly what I need. I was playing around with
content_redraw again today and got something which appears to work
through trial/error.
Has the redraw / scrolling / text input editing speed improved at all?
If redrawing background images is slow, it may be because the background
image tiles are very small. The GTK front end pre-tiles small background
images which speeds up rendering there. The RISC OS front end doesn't need
to do that because it is done automatically by Tinct, which we use for
image rendering.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
10:39 p.m.
On Sat, 07 Feb 2009 11:06:45 +0000 (GMT), Michael Drake wrote:
> That looks like exactly what I need. I was playing around with
> content_redraw again today and got something which appears to work
> through trial/error.
Has the redraw / scrolling / text input editing speed improved at all?
Text input speed is much improved, however animated GIFs no longer
display correctly - in some cases they only redraw (update to next
frame) when I scroll. I guess either the scheduler is broken -
although I haven't touched it - or somehow the redraws are getting
missed. Other animated GIFs are animating, but where the animation is
it's getting distorted. Appears to be calling the bitmap draw routine
with values that mean it gets scaled up before being drawn.
Chris
12:42 a.m.
In article <50270135e0tlsa(a)netsurf-browser.org>,
Michael Drake <tlsa(a)netsurf-browser.org> wrote:
So in riscos/window.c, ro_gui_window_redraw:
ro_plot_origin_x = redraw->box.x0 - redraw->xscroll;
ro_plot_origin_y = redraw->box.y1 - redraw->yscroll;
Gets the coordinates of the top left of the area of the page/canvas
which is at the top left of the visible area.
Sorry, that's a mistake. The os_box 'box' and 'clip' are in have the
origin at the screen bottom right. So that should be:
ro_plot_origin_x = redraw->box.x0 - redraw->xscroll;
ro_plot_origin_y = redraw->box.y1 - redraw->yscroll;
Gets the coordinates of the top left of the area of the page/canvas
in screen coordinates.
clip_x0 = (redraw->clip.x0 - ro_plot_origin_x) / 2;
clip_y0 = (ro_plot_origin_y - redraw->clip.y1) / 2;
clip_x1 = (redraw->clip.x1 - ro_plot_origin_x) / 2;
clip_y1 = (ro_plot_origin_y - redraw->clip.y0) / 2;
Gets the area of the page/canvas requested for redraw in NetSurf units,
from the origin at the top left of the page/canvas:
left: clip_x0
top: clip_y0
right: clip_x1
bottom: clip_y1
(i.e. the origin for the clip values is the top left of the document.)
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
12:33 p.m.
In article
<OUT-4982485F.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
On Thu, 29 Jan 2009 23:16:38 +0000 (GMT), Michael Drake wrote:
> > I get sluggish scrolling on some sites,
> Which sites? Scrolling speed is fast here and doesn't vary
between
> sites.
Mostly ones with complicated amounts of imagery - eg.
http://www.bbc.co.uk is really slow.
Did this get fixed?
I dunno if it's relevant, but I recently updated the info for the tiled
bitmap plotters:
http://source.netsurf-browser.org/trunk/netsurf/desktop/plotters.h?r1=636...
So it now explains what x and y are and that the extents of the repeat (if
repeating) will be given by the currently set clip rectangle.
It looks like the Amiga plotters use scrn-Width and scrn->Height for the
tiled plotting extents. I don't know what they are but the clip rectangle
will be the size of the visible bit of canvas as a worst case and
generally smaller.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
6:36 p.m.
On Tue, 24 Feb 2009 11:33:13 +0000 (GMT), Michael Drake wrote:
> > > I get sluggish scrolling on some sites,
> > Which sites? Scrolling speed is fast here and doesn't vary between
> > sites.
> Mostly ones with complicated amounts of imagery - eg.
> http://www.bbc.co.uk is really slow.
Did this get fixed?
Not really :(
I dunno if it's relevant, but I recently updated the info for the
tiled
bitmap plotters:
http://source.netsurf-browser.org/trunk/netsurf/desktop/plotters.h?r1=636...
So it now explains what x and y are and that the extents of the repeat (if
repeating) will be given by the currently set clip rectangle.
It looks like the Amiga plotters use scrn-Width and scrn->Height for the
tiled plotting extents. I don't know what they are but the clip rectangle
will be the size of the visible bit of canvas as a worst case and
generally smaller.
scrn->Width and scrn->Height are the screen's dimensions, which is
also the size of the off-screen bitmap. It's not massively different
to the visible area if the window is fully extended.
I think the speed problem is mainly due to alpha blits being very
slow, but I can't speed them up.
Chris
7:31 p.m.
New subject: Slow scrolling on Amiga port
In article
<OUT-49A43009.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
On Tue, 24 Feb 2009 11:33:13 +0000 (GMT), Michael Drake wrote:
> Did this get fixed?
Not really :(
scrn->Width and scrn->Height are the screen's dimensions,
which is
also the size of the off-screen bitmap. It's not massively different
to the visible area if the window is fully extended.
OK, so that is wrong. If the clip rectangle is used for the extents the
area will mostly be much smaller, especially for sites like BBC that use a
lot of background images on different bits of the page.
The one in framebuffer/fb_plotters.c is pretty simple to follow, although
the framebuffer port currently lacks scaling support, so it's a bit more
simple.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
12:53 a.m.
New subject: Slow scrolling on Amiga port
On Tue, 24 Feb 2009 18:31:09 +0000 (GMT), Michael Drake wrote:
> scrn->Width and scrn->Height are the screen's
dimensions, which is
> also the size of the off-screen bitmap. It's not massively different
> to the visible area if the window is fully extended.
OK, so that is wrong. If the clip rectangle is used for the extents the
area will mostly be much smaller, especially for sites like BBC that use a
lot of background images on different bits of the page.
The one in framebuffer/fb_plotters.c is pretty simple to follow, although
the framebuffer port currently lacks scaling support, so it's a bit more
simple.
OK, I nicked that code after tampering with mine and then deciding it
was easier just to copy'n'paste.
It's definitely faster, although still not as quick as I'd like.
amigaworld.net is a little slow, it seems to have hundreds of alpha
pixels plotted over the articles.
Tiled images that are partly scrolled off the top of the screen don't
plot any more.
Chris
2:03 p.m.
New subject: Slow scrolling on Amiga port
In article
<OUT-49A4887D.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
On Tue, 24 Feb 2009 18:31:09 +0000 (GMT), Michael Drake wrote:
It's definitely faster, although still not as quick as I'd
like.
amigaworld.net is a little slow, it seems to have hundreds of alpha
pixels plotted over the articles.
Pages on that site are no slower than any other page on the RISC OS
version. Are you using the bitmap opacity information? The core tells the
front end if a bitmap is completely opaque, so that the plotter may use a
faster and more optimal method for plotting opaque images.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
7:16 p.m.
New subject: Slow scrolling on Amiga port
On Thu, 05 Mar 2009 13:03:16 +0000 (GMT), Michael Drake wrote:
Pages on that site are no slower than any other page on the RISC OS
version. Are you using the bitmap opacity information? The core tells the
front end if a bitmap is completely opaque, so that the plotter may use a
faster and more optimal method for plotting opaque images.
I am, but it is possible I've done something wrong.
NB it is only the front page of amigaworld.net which is slow, the rest
are OK.
Chris
8:56 p.m.
On Tue, 2009-01-27 at 20:01 +0000, Michael Drake wrote:
So the possible ideas so far are:
1. Native Windows or Mac OS X ports
2. Keyboard navigation
3. Page reader
4. Extracting the core into a library
This either needs specifying properly or dropping from the list. The
issue we had with this last time is that it's far too open-ended.
5. Layout engine improvements
As above. What improvements?
6. LibDOM
This one, like Hubbub was last year, is well constrained (although,
unlike Hubbub, it has the potential to get out of control). Best, I
think, is to limit it to Core, Events, and possibly HTML.
7. LibSVGTiny
James: have you any thoughts about this? I have little idea of what the
current state is, what needs doing, and how much work it might be.
8. Automated NetSurf layout test suite
Again, needs specifying properly.
9. Improved GTK front end
10. Improved Haiku/BeOS front end
11. Improved RISC OS front end
What improvements (for all 3)?
It would be good to have some more core related ones, I think. How
about
that idea that's popped up a few times about allowing NetSsurf to make a
report of all errors and problems found with the HTML and CSS of a page
and the rewrite of NetSurf's internal logging handling?
Rewriting logging is desirable. That said, I don't envisage it being a
full summer's work for a half-competent student. Note that logging parse
errors from the current CSS code is probably somewhat of a waste of
time, given it'll likely be replaced some point during the GSoC cycle.
Also how about an idea related to general browsing efficiency, for
example
only decoding images when they need to be displayed, making a disc cache,
and other stuff? Don't know how much work there is in that kind of thing.
Again, this needs specifying properly.
Additionally, this lot needs turning into an ideas page asap. We should
also work on the application form. I transcribed last year's answers to
the wiki and suggest we just work on it there.
J.
2:48 a.m.
> 1. Are we intending to apply this year?
Yes, I think it's certainly worth it. :)
+1
1. New CSS parser and selector engine
2. Native Windows or Mac OS X ports
I already had the core building with mingw at some point, sadly I lost
the latest version when the outsourced server hosting company my boss
was using went out of business and the liquidator pulled the plug
without warning.
I have an old patch though, that could still be of use:
http://revolf.free.fr/beos/patches/netsurf_mingw_core_r4457.diff.txt
3. Keyboard navigation
That's quite useful for disabled people who can't use the mouse, and
others who want to go faster without it.
11. Improved GTK front end; tabs, downloads, etc
Haiku will probably also participage in GSoC again, maybe we could get
a common one on improving the BeOS/Haiku port. I wasn't able to work on
it recently.
François.
4:24 p.m.
On Thu, 15 Jan 2009, François Revol wrote:
I already had the core building with mingw at some point, sadly I
lost
the latest version when the outsourced server hosting company my boss
was using went out of business and the liquidator pulled the plug
without warning.
I have an old patch though, that could still be of use:
http://revolf.free.fr/beos/patches/netsurf_mingw_core_r4457.diff.txt
Cool. Thanks for that.
> 11. Improved GTK front end; tabs, downloads, etc
Haiku will probably also participage in GSoC again, maybe we could get
a common one on improving the BeOS/Haiku port. I wasn't able to work on
it recently.
Sounds useful. Would you be available to mentor such a project?
J.
3:11 a.m.
2. Native Windows or Mac OS X ports
I would love to see this done, and would even be interested in applying for
the Windows port. Of course, fandango is still my priority, so maybe
someone else will pick this up.
11. Improved GTK front end; tabs, downloads, etc
>>
>
> Haiku will probably also participage in GSoC again, maybe we could get
> a common one on improving the BeOS/Haiku port. I wasn't able to work on
> it recently.
Sounds useful.
+1
[fandango]
> 9. Is currently partially done. We would need to assess exactly how
> much more is needed for this.
>
Sean? Can you comment on this?
Fandango is definitely still a work-in-progress. I'm fairly confident there
is enough remaining work to keep someone busy for 10 weeks. The first
things that come to mind are mouse and text-related things: text selection,
copying/pasting, drag and drop, and frame resizing. The hierarchy of
structures (i.e. newly introduced fandango_ctx) could use better
documentation and maybe a bit of clean-up. Lots of things could use
improved error-handling or exchange of status/information; perhaps you would
call this "polishing" the API. There is still work to be done regarding
cookies and objects (images, etc); I don't recall this code very well, so
I'm not certain how much work will be required in that area. It's entirely
possible I'm forgetting things, but these are sections I'm aware of that
need work.
I suspect a large amount of the work would also be on fantesto, which is the
test application for fandango. Since fantesto is just an old NetSurf
revision with unimplemented/broken sections commented out, it's basically
the prototype for the first NetSurf build that will utilize fandango upon
completion. Once this work is completed someone will need to merge the last
several months of NetSurf updates back into fantesto (or vice-versa,
whichever seems simpler), which will likely create some headaches.
With solid work over 10 weeks, it's plausible that fandango would reach a
level of quality suitable to merge into the development branch. I'll be
applying for this particular project, of course. But regardless of who is
accepted, these would be my expectations--unless I've forgotten something
drastically time-consuming.
Sean
5136
days inactive
5186
days old
netsurf-dev@netsurf-browser.org
28 comments
5 participants
participants (5)
-
Chris Young -
François Revol -
John-Mark Bell -
Michael Drake -
Sean Fox