5:16 p.m.
Build: 07 Aug 01:45 RO 3.70/3
When a window is being drawn on screen it seems to arrive frame first,
with the central section transparent showing other windows/pinboard
through it, then the content arrives.
Every time this happens I tense myself expecting a crash (because in
the past other apps that have done this have produced a crash). Is
this behaviour intentional - perhaps related to the window drawing
probelm that I recently reported (which you fixed)?
--
Jeremy C B Nicoll - my opinions are my own.
4:27 a.m.
Jeremy C B Nicoll <Jeremy(a)omba.demon.co.uk> wrote:
Build: 07 Aug 01:45 RO 3.70/3
When a window is being drawn on screen it seems to arrive frame first,
with the central section transparent showing other windows/pinboard
through it, then the content arrives.
Every time this happens I tense myself expecting a crash (because in the
past other apps that have done this have produced a crash). Is this
behaviour intentional - perhaps related to the window drawing probelm that
I recently reported (which you fixed)?
This is probably result of the changes that make background images extend
to the window dimensions as opposed to the content dimensions. I'll try and
reproduce when I get back from work and fix.
R.
--
Richard Wilson, Publications Manager
Tradelink Publications Ltd.
4:35 a.m.
On Mon, 9 Aug 2004, Richard Wilson wrote:
Jeremy C B Nicoll <Jeremy(a)omba.demon.co.uk> wrote:
>
> Build: 07 Aug 01:45 RO 3.70/3
>
> When a window is being drawn on screen it seems to arrive frame first,
> with the central section transparent showing other windows/pinboard
> through it, then the content arrives.
>
> Every time this happens I tense myself expecting a crash (because in the
> past other apps that have done this have produced a crash). Is this
> behaviour intentional - perhaps related to the window drawing probelm that
> I recently reported (which you fixed)?
This is probably result of the changes that make background images extend
to the window dimensions as opposed to the content dimensions. I'll try and
reproduce when I get back from work and fix.
Alternatively, it's a result of Display->Render->Buffer all rendering
being selected. This does slow NetSurf down somewhat considerably (it's
off by default)
John.
8:08 a.m.
In article
<Pine.LNX.4.44.0408090933450.28773-100000(a)tarrant.ecs.soton.ac.uk>,
John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
Alternatively, it's a result of Display->Render->Buffer all
rendering
being selected. This does slow NetSurf down somewhat considerably
(it's off by default)
That IS on.
Is this something that I must have turned on myself? That would
surprise me because I wouldn't normally change a default, especially
one whose purpose I don't really understand.
When would use of the buffering option be sensible?
--
Jeremy C B Nicoll - my opinions are my own.
9:43 a.m.
On Mon, 9 Aug 2004, Jeremy C B Nicoll wrote:
In article
<Pine.LNX.4.44.0408090933450.28773-100000(a)tarrant.ecs.soton.ac.uk>,
John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
> Alternatively, it's a result of Display->Render->Buffer all rendering
> being selected. This does slow NetSurf down somewhat considerably
> (it's off by default)
That IS on.
Is this something that I must have turned on myself?
Perhaps, perhaps not ;)
I believe there was a small issue with the options handling at one point
(buffer everything was ignored completely, but the value saved in the
choices file was "on", even though the default is "off"). What I
suspect
has happened is that you've saved your choices at some point whilst
running a NetSurf build which exhibited this broken behaviour. As we've
fixed the issue, the value in your choices file is being used (which will
erroneously be set to "on"). Therefore, my advice would be to turn it off
via NetSurf's menu system and resave your choices.
That would surprise me because I wouldn't normally change a
default,
especially one whose purpose I don't really understand.
When would use of the buffering option be sensible?
Mike's already posted the reference to the documentation. However, there's
an issue with the documentation in that the textarea buffering occurs when
buffer animations is selected (the default) and *not* when buffer all
rendering is selected (as the documentation indicates).
Hope that sheds some light on the issue.
John.
11:22 a.m.
In article
<Pine.LNX.4.44.0408091433540.31245-100000(a)tarrant.ecs.soton.ac.uk>,
John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
On Mon, 9 Aug 2004, Jeremy C B Nicoll wrote:
> Is this something that I must have turned on myself?
Perhaps, perhaps not ;) I believe there was a small issue ....
Therefore, my advice would be to turn it off via NetSurf's menu
system and resave your choices.
Ah, that makes some sense - I *did* save a load of stuff as default
quite a while ago. And I'll do that.
... textarea buffering occurs when buffer animations is selected
(the default) and *not* when buffer all rendering is selected (as the
documentation indicates).
Hope that sheds some light on the issue.
It does, thank-you. Though... what's a text area - is it just any
piece of text or does it have a more specific meaning?
--
Jeremy C B Nicoll - my opinions are my own.
11:54 a.m.
On Mon, 9 Aug 2004, Jeremy C B Nicoll wrote:
In article
<Pine.LNX.4.44.0408091433540.31245-100000(a)tarrant.ecs.soton.ac.uk>,
John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
[snip]
> ... textarea buffering occurs when buffer animations is
selected
> (the default) and *not* when buffer all rendering is selected (as the
> documentation indicates).
> Hope that sheds some light on the issue.
It does, thank-you. Though... what's a text area - is it just any
piece of text or does it have a more specific meaning?
In this case, a <textarea> form element on a webpage (for example, the
comment box at the bottom of every drobe article).
John.
12:37 p.m.
New subject: [Netsurf-develop] Re: window drawing?
John-Mark Bell wrote:
On Mon, 9 Aug 2004, Jeremy C B Nicoll wrote:
> Though... what's a text area - is it just any piece of text
or does
> it have a more specific meaning?
In this case, a <textarea> form element on a webpage (for
example,
the comment box at the bottom of every drobe article).
Ah, while on the topic of textareas: Any chance of supporting the
plug-in protocol so that ZapPlugIn can be used for textareas? See
http://sudden.recoil.org/zap/index.php for ZapPlugIn and
http://zap.tartarus.org/ for Zap itself.
--
Stefan Bellon
11:56 a.m.
Jeremy C B Nicoll <Jeremy(a)omba.demon.co.uk> wrote:
> ... textarea buffering occurs when buffer animations is
selected (the
> default) and *not* when buffer all rendering is selected (as the
> documentation indicates).
> Hope that sheds some light on the issue.
It does, thank-you. Though... what's a text area - is it just any piece
of text or does it have a more specific meaning?
The bits you type into in forms. Basically what RISC OS would refer to as a
writable icon.
R.
--
Richard Wilson, Publications Manager
Tradelink Publications Ltd.
9:46 a.m.
Jeremy C B Nicoll <Jeremy(a)omba.demon.co.uk> wrote:
In article
<Pine.LNX.4.44.0408090933450.28773-100000(a)tarrant.ecs.soton.ac.uk>,
John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
> Alternatively, it's a result of Display->Render->Buffer all rendering
> being selected. This does slow NetSurf down somewhat considerably (it's
> off by default)
That IS on.
Is this something that I must have turned on myself? That would surprise
me because I wouldn't normally change a default, especially one whose
purpose I don't really understand.
There was a bug in the options table that caused the setting for animation
buffering to be used for complete buffering too. This got fixed a while ago,
but it could be the reason the option got changed.
When would use of the buffering option be sensible?
My advice would be to always have "Buffer animations" turned on, and never
have "Buffer all rendering" on unless you have a fast machine or really
really hate flicker. Incidentally, the buffering of animations will also
cause text areas to be buffered and any flicker removed - the documentation
is currently incorrect in this respect.
An simple example of the difference it makes can be seen via a site such as
www.cube-europe.com. Load the page then scroll about using Page Up/Page Down
(so you get a full page drawn each time) to see the difference between the
two settings.
Speed is noticeably slower when buffering is used as the relevant area of
the screen is grabbed as a Sprite, this is then drawn to, and then finally
the Sprite is plotted back.
R.
--
Richard Wilson, Publications Manager
Tradelink Publications Ltd.
11:25 a.m.
In article <gemini.i26m8u000ioyz010g.richard(a)coalinternational.co.uk>,
Richard Wilson <richard(a)coalinternational.co.uk> wrote:
> When would use of the buffering option be sensible?
My advice would be...
Thanks very much for explaining this, especially giving me an example
to go and experiment with. It pads out the documentation which, while
accurate, doesn't give one much idea why one or other choice would be
best...
--
Jeremy C B Nicoll - my opinions are my own.
11:54 a.m.
Jeremy C B Nicoll <Jeremy(a)omba.demon.co.uk> wrote:
In article <gemini.i26m8u000ioyz010g.richard(a)coalinternational.co.uk>,
Richard Wilson <richard(a)coalinternational.co.uk> wrote:
> > When would use of the buffering option be sensible?
> My advice would be...
Thanks very much for explaining this, especially giving me an example to
go and experiment with. It pads out the documentation which, while
accurate, doesn't give one much idea why one or other choice would be
best...
That's somewhat my fault for not explaining to Michael quite what the
options did as he continued his sterling job keeping documentation in line
with a rapidly changing application.
R.
--
Richard Wilson, Publications Manager
Tradelink Publications Ltd.
3:30 a.m.
On 9 Aug, Richard Wilson wrote:
Jeremy C B Nicoll <Jeremy(a)omba.demon.co.uk> wrote:
> In article
> <Pine.LNX.4.44.0408090933450.28773-100000(a)tarrant.ecs.soton.ac.uk>,
> John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
>
> > Alternatively, it's a result of Display->Render->Buffer all
rendering
> > being selected. This does slow NetSurf down somewhat considerably (it's
> > off by default)
[snip]
> When would use of the buffering option be sensible?
My advice would be to always have "Buffer animations" turned on, and never
have "Buffer all rendering" on unless you have a fast machine or really
really hate flicker. Incidentally, the buffering of animations will also
cause text areas to be buffered and any flicker removed - the documentation
is currently incorrect in this respect.
An simple example of the difference it makes can be seen via a site such as
www.cube-europe.com. Load the page then scroll about using Page Up/Page Down
(so you get a full page drawn each time) to see the difference between the
two settings.
Speed is noticeably slower when buffering is used as the relevant area of
the screen is grabbed as a Sprite, this is then drawn to, and then finally
the Sprite is plotted back.
On that site I find that without buffering it seems much slower and is
much more annoying since it redraws everything from the background
forward. With buffering on it's quite nice, but I was very surprised to
note that it's slower than O2 in either mode, both in initially loading
the page and all its graphics, and then enlarging the window/ scrolling
around in it. Is there something about this particular site that makes
Netsurf slower than it normally might be, or is rendering still a work
in progress?
(On an Iyonix, build 09 Aug 17:15)
--
Sendu Bala http://sendu.me.uk/ | Tori, Kenshin, DNA and my Iyonix
"I tell you with no ego that this is my finest blade. If you should
encounter God, God will be cut."
7:23 p.m.
New subject: [Netsurf-develop] Re: window drawing?
In article <7add28dc4c.Sendu(a)sendu.me.uk>,
Sendu Bala <sendu(a)sendu.me.uk> wrote:
[snip]
On that site I find that without buffering it seems much slower and
is
much more annoying since it redraws everything from the background
forward. With buffering on it's quite nice, but I was very surprised to
note that it's slower than O2 in either mode, both in initially loading
the page and all its graphics, and then enlarging the window/ scrolling
around in it. Is there something about this particular site that makes
Netsurf slower than it normally might be, or is rendering still a work
in progress?
NetSurf was slower than it could have been at plotting opaque images and
this was particularly apparent on an Iyonix. Richard has just made some
optimizations for plotting opaque images and the improvement on an Iyonix
is staggering. :)
Cheers,
Mike
--
Michael Drake - (tlsa)
Check my website: http://www.smoothartist.com/
6141
days inactive
6199
days old
netsurf-users@netsurf-browser.org
13 comments
6 participants
participants (6)
-
Jeremy C B Nicoll -
John-Mark Bell -
Michael Drake -
Richard Wilson -
Sendu Bala -
Stefan Bellon