Re: [MiNT] Highwire / Netsurf was: [Launcher]

[m0n0 <ole@monochrom.net>]

Am Montag, den 13.09.2010, 14:13 +0200 schrieb Peter Slegg
<p.slegg@scubadivers.co.uk>:

> How do I generate a log ?

the commandline option -v enables verbose output. to redirect it to an
logfile you could do the following:

nsfb -v file:///e/foobar.html 2> netsurf.log


> Hopefully gcc4 is finding horrible stuf and I will try to fix it in
> a less encrypted style where I can.

Horrible stuff? It seems HW is running quite well, so what do you
expect to find. I don't see any really serious reason why HW should be
compiled with gcc4 - as long as gcc2.95 can coexist with gcc4...
 
This is really getting off-topic and should be discussed in the HW ML -
but did you add the new RSC file to your HW build? 

> Netsurf looks huge and I wouldn't know where to start. Is you aim to convert
> it to GEM app first ?

Uhm... I just need to add instructions on what to patch in the SDL
framebuffer Makefile / src. Then the compiling instructions are
complete. So a good start is: 
http://nic-nac-project.org/~monokrom/monochrom.net/atari/netsurf.htm :D


If there is another one that can compile the framebuffer version, It
would be more relaxed. As the GEM port will take take much of my time.
If there is the framebuffer version available and is getting build with
the SVN changes, that would relax the need for an native GEM port..., as
we always have the framebuffer fallback if something is not working in
the native port. So I'm talking about compiling the framebuffer version.

Yes I'm planning to do an native GEM port, to be exact: it takes to
much of my free time ;)
I'm currently at developing the native graphics plotters... which
results in more complexity than I like,
because I would like to have 2 possible implementations of graphics
plotters:

- One version that uses offscreen buffers, all drawing routines are
done to the offscreen buffer when content needs to be redrawn. When an
WM_REDRAW message occurs, the offscreen buffer is simply copied into the
screen buffer. This has one advantage: it's faster when WM_REDRAW
occurs, because the content doesn't needs to be plotted again, it just
gets copied. Disadvantage: needs way more memory...

- One version that directly renders into the screen buffer... this has
one advantage: less memory usage.  The disadvantage: every redraw needs
many calls to the plotter functions like: draw_string, draw_circle etc.

When I understand it right, these both approaches need to take
different code path, different handling of new page content, different
handling of WM_REDRAW message,... 

I'm not quite sure if it is worth to implement the direct-to-screen
rendering... I want it because my falcon has 10 MB free ram after
bootup, and it would be cool if netsurf could run on it without memory
exhaust.
And it can be used for an very compatible plotter based on VDI
functions...