[Netsurf-develop] Thoughts and planning

James Bursa bursa at users.sourceforge.net
Mon Jul 29 21:07:01 BST 2002

In message <4bda595d4b%phil at mellor123.freeuk.com>
          Phil Mellor <phil at mellor123.freeuk.com> wrote:

> C is good.  I like C.  At the moment my work involves me writing in
> C--, which is C with all the nasty bits like macros and unions and 
> taken out, and everything else must be entirely legal.  I'm also a
> fan of eXtreme programming, where you keep comments to a minimum,
> but use incredibly meaningful variable and function names, in an
> attempt to keep the code self-documenting.  There's more to X-P
> than that, and it's quite an interesting and effective approach.
> I think in attempt to avoid horrible buginess (the sort that will
> never get fixed) we should try to follow similar principles.
> Highly modular code, each bit black-box tested before being put
> in the main program.  And I know it's tedious, and perhaps
> inefficient, to keep checking for NULL pointers and things all
> over the place, but it does make debugging easier since you can
> notice where something goes wrong.  We should aim for greater
> stability than Fresco!
> That's my software engineering rant over. :*)

OK, we're agreed on C. I think you're right that we should program
defensively, with lots of assert()s etc. We need to keep security in mind
too, and not trust anything from the net. Shame we can't do pair

> > - HTTP implementation (libcurl ?)
> Ermm... yes.  Without looking at how this works, I have no idea
> how this works.  Could we have some sort of abstraction layer
> over the program, so it doesn't matter whether the data comes
> from file, http, or even from another application via WIMP
> messages?

Sounds like a good idea. I've managed to get libcurl to fetch a page on
RISC OS, so at least we could start by using it.

> > - image renderers / converters
> Now this is interesting, because a lot of it has been done before.
> JPEG rendering is built into the OS, which is nice, and doesn't
> RISC OS Select include support for PNGs?  Would it be better to
> incorporate other formats into the code, or use helper applications
> like InterGif, ChangeFSI, which could run in TaskWindows?
> What about ImageFS?  Could that be used somehow?

Definitely incorporate into the code for speed. Apparently launching helper
applications is one of the things that makes Webster slow.

> It would be a bit inefficient (memory wise) to convert byte-sized 
> GIFs into stonking great sprites before plotting them, but on the
> other hand rendering GIFs on the fly would be slow.  Maybe some
> combination -- convert small or oft-used images for efficiency,
> but leave large ones in native format.
> There are also animated and interlaced images to consider.

I guess we could try direct rendering, and if it's too slow convert
instead. I find the OS JPEG renderer slow when I'm using Browse.

> > - RISC OS wimp interface
> I think this needs a lot of thought.  Something innovative needs
> to be done, that uses the strengths of RISC OS.  Drag and drop
> should be used heavily -- perhaps you could drag images straight
> out into a filer window or other application, and do StrongED
> style selecting blocks of text and dragging it out.
> Dragging with Select could leave the object in native format,
> with Adjust could export the most RISC OS-y conversion.

Nice idea.

> I often read web pages by selecting the text as I read it; the
> computer equivalent of running your finger along the lines, and
> it would be nice if you could do that in NetSurf.
> But all that's putting the cart before the proverbial horse.
> We definitely need support for multiple windows, which could
> easily be turned into Opera-style tabbed browsing if necessary.
> Is it right that most RISC OS browsers don't put scroll bars
> in frames?  That needs to be done properly.  If we only support
> the nested window manager (which can be softloaded onto any RO3
> machine) things should be much easier.

For me, frames are low priority, since few good websites use them anymore.

> Are we going to use an existing WIMP library, like OSLib, the
> Toolbox, or Jason Tribbeck's recent thing?  Or the one on the
> Coders Cauldron that I think Phlamethrower was working on?
> When I write WIMP applications I don't generally use an
> existing library, mainly because the documention is poor and
> I don't find I have the nitty-gritty control that I need.
> Maybe we only need to write a nice set of functions that sit
> over the Wimp_* SWIs.

I've used OSLib so far. OSLib is just a C interface to RISC OS SWIs, not a
WIMP library. I think we should use the WIMP directly through OSLib.

> It might be best to keep the interface as abstract as possible.
> Then porting to another platform, or at least altering or
> improving the interface, need be as painless as possible.

Sure, all the platform-dependent code should be separate.

> > - font handling (unicode ?)
> I think we need to be future-proofed for Unicode, even if the
> Font Manager can't render it.  
> Some sort of text string structure which can hold any form
> of text:
> struct String
> {
>   int encoding;   /* String_Latin1, String_Unicode, etc */
>   int length;
>   void* string;   /* can hold char*, short int* */
> };
> and a set of functions:
> ...
> etc... are needed.  Other facilities to concatenate two strings,
> perform atoi() style conversions etc, can be done as further
> String_... functions.  Anything to do with text should use Strings,
> and always via the function interfaces, never with the internal
> data.  This should make it possible to mix and match all the
> different text formats throughout the program, if necessary.

Libxml converts other encodings to UTF-8 when it parses HTML files, so
maybe it would be better to use that or another Unicode encoding

> I've done some work rendering and formatting text using the
> Font Manager before; the fun lies in the special RISC OS control
> characters that are used to format the text, such as 26 to change
> to a different font/size, 18/19 to change colour, 25 to underline.
> It's probably best to represent these as something separate,
> perhaps an array of attribute+string structures.

At the moment the layout code makes a separate text box for each change in
font or style, so we wouldn't need this.

> * Embeddedness
> You know how you keep getting HTML e-mails?  Wouldn't it be nice if
> Messenger could render them properly?  If the NetSurf HTML rendering
> engine could be used by other applications, that would be nice.
> It might be a case of running a copy of NetSurf with the browser
> window as a pane within the other application's window, but it
> would be nice protocol for the platform to support.

Lots of apps could find this useful. It would need an option to disable
fetching external stuff.

> * Rendering
> Now, I've seen some snazzy things done on web pages these days, with
> things like images that stay in a fixed position when you scroll
> the window, and crazy stars that follow the mouse pointer around the
> screen.  I know some of that is done with JavaScript, but even so I
> don't think that rendering to a DrawFile (which I understand is how
> some other browsers, such as Webite, ArcWeb and perhaps Fresco do it)
> is going to be enough.
> There might be some major plotting done each time the window is
> scrolled or redrawn; it might be nice to render to a sprite which is
> then plotted on screen.  I know it's memory hungry, particularly
> in hi-res deep colour modes, but it would make things look snazzier
> with no irritating flicker. Maybe it could be optional.

I think direct rendering is best, not DrawFiles. We could do the sprite
thing if it's too slow.

> * Multitasking
> Is this important? Probably.  I've seen complaints at how Fresco
> freezes for a while when faced with complex table structures.
> On the other hand, RISC OS isn't particularly pre-emptive or
> multi-threaded.
> There are a number of approaches:
>  a) Forget it. Wait until RISC OS Ltd get it sorted.
>  b) Try and get the program to work properly with Niall Douglas'
>     Wimp2 thing.
>  c) Construct the program in such a way that works around it.

> Here's my first thought on how to do things:
> main loop:
> repeat
> {
> ...
> } until quit;
> The process action section is the most important.  I think it's important
> to not let any action take too long, and should always keep an eye on
> the clock and pause itself if necessary.  Therefore a "render document"
> action could immediately break itself down into a number of smaller
> actions, a divide and conqueor approach.  Each action could be allocated
> a proportion of the overall time quota, or could only do a little of its
> task before returning, otherwise one action at the start of
> the queue could hog the entire process creating a bottleneck (eg.
> converting a GIF in one window could prevent another document from
> being formatted).

Looks complicated. I'd prefer to avoid splitting up code if possible,
because things like the layout code are very recursive. It would be
possible to add Wimp_Polls which only handle urgent events and queue the
rest at places in it though, to give other apps CPU time. Ideally it'll be
so fast that it won't be necessary ;->.

I guess the first priority is making sure you can compile it. You'll need
libxml, oslib, and libcurl. I could upload compiled libxml and libcurl if
you want. I think the RO CVS port can download from SourceForge CVS.


More information about the netsurf-users mailing list