Re: NetSurf 1.0 released

In article <1180014984.237157.55660@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Richard Wilson <not.ginger.matt@xxxxxxxxx> wrote:
On 24 May, 14:22, David <nos...@xxxxxxxxxxxxxxxxxxxxx> wrote:
In article <1180011169.964698.35...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,

[snip description of the basic structure of a NS GUI window]

Thank you. Very much. This is the sort of answer I've been trying
to get. Ignoring the status bar (which, as I said, isn't in
NS-CVS), I note that you say a "special" thing happens regarding
the movement of icons in a parent window resize but I suppose
you're referring to the icons in the toolbar.

The status bar is one of the components I've finished rewriting to
use UTF-8 and modularised. As such it is in SVN at /risos/gui/
(rather than the standard /riscos/) and you can browse the relevant
code online at
http://source.netsurf-browser.org/trunk/netsurf/riscos/gui/ if you
want. The icons that move in the toolbar are the URL icon (resized),
the recent url icon and throbber icon. In the status bar it's just
the resize widget that's moved (the text is drawn manually by NetSurf
so it can correctly display UTF-8.)

Sorry but C is out of my league (which is limited to bad Basic).

I do wonder about the "minimal window redraw rectangle", though.

Redraw is only requested for the affected area, which is the minimal
change from the right edge of the inset of the URL icon to the edge
of the window. This helps prevents as much flicker as possible
(compared with redrawing the entire window). If we didn't request any
redraw at all the only issue would be the toolbar window would
contain redraw artifacts on the right hand side. It would not affect
anything outside of the toolbar window, converse to what is seen in
the screenshot you kindly provided.

I'm not entirely certain of what you're telling me here. There must be
times when you need to redraw the entire window to fit the displayed
web page into its width.

I've had times when moving a window of mine has left the original area
unreplaced by whatever's beneath it and that's been due to my code not
completing the redraw sequence. Same if parts of my window remain not
updated. So to me it sounds as though something is limiting the redraw
cycle. As I've said before, other apps with dependent windows,
presumably using the nested window manager, don't suffer this problem
and I can't see why they shouldn't if 3DPatch is to blame.

Calling Martin Wuerthner: Martin, does TW use the nested window manager?

Having done some further tests, I can now provide a fuller
description of what happens.

Vertical resizing has no error and the window redraws correctly.

Horizontal resizing: by setting mousestep to 1, I see that the
toolbar is redrawn correctly and the contents of the main window
also seem to be adjusted and redrawn correctly. The right side
furniture, however, is not redrawn at all during the leftward
resizing and only gets redrawn if there is also some vertical
resize (just one pixel will do). Releasing the mouse button without
having done any vertical resize leaves the right side of the window
and the vacated part of screen unredrawn - except for the resize
icon (-9) itself which is redrawn on release of the mouse button.

I'd like to add here that the bottom, horizontal scrollbar also remains
undrawn in this case. The resize icon sits there all alone.

Also that NS-v1.0 produces slightly different redraw problems in that
the resize icon is drawn on its own and then a split second later, the
other window furniture appears correctly in the new place. The old
vacated area is not redrawn, though, like the CVS version.

As only the WIMP redraws window furniture, I'd strongly move away
from it being a NetSurf problem. Quite what the problem is requires
setting up a suitable test environment and writing some suitable code
as test-cases. Thanks for your description -- it should help with
this.

I'm not really trying to make unnecessary work for you and if I'm the
only person affected you can probably safely leave it. As I said,
though, it'd niggle me if it happened to one of my programs.


I don't know if 3DPatch itself causes this or whether is is some
rare problem in the way NS is coded which (so far) only shows up in
conditions made different by 3DPatch. And I'm not been picky for
the sake of it. As a programmer, you should know the dangers of
making assumptions about where the source of a problem lies.

It may not be 100% that it's 3dpatch's issue, but I'd happily offer
odds of a penny to a pound right now. Whilst it's foolish to assume,
it's logical to direct the most available resources towards the issue
which looks the most promising.

Yes, I've already said it's quite probably just the fault of 3DPatch
and I appreciate there's much more urgent work to be done on NS.

However, if you do want to pursue the matter I'd be more than happy to
help as much as I can by email.

--
New Marmite(TM): Not as thick! Not as dark! Not as te!

David - toro-danyo atcost uku fullstop co fullstop uk
http://www.toro-danyo.uku.co.uk/
.