On Tue, 2010-02-02 at 21:33 +0200, Bernd Roesch wrote:

> I get more and more in mind netsurf team want no feature rich SDL netsurf

It's really very simple:

1) The framebuffer frontend is not designed for use in a windowed 
   environment. This will not change, as the whole point is that it 
   targets fixed-size framebuffers.

2) The SDL binding in libnsfb is *purely* for debugging and 
   demonstration of the framebuffer concept. It is absolutely not 
   designed to be used for anything else.

Therefore, the correct way to produce a SDL version of NetSurf suitable
for windowed environments is to write a frontend that uses SDL directly,
and does not use the framebuffer frontend or libnsfb in any way.

However, as that work is extremely likely to require far more effort
than a native Amiga OS 3 port (particularly given Chris' comments about
the likely difficulty of backporting his Amiga OS 4 port) our strong
preference is for a native port.

> so there need not write and keep upto date a own plotter interface

I really don't understand what is so difficult here.

Firstly, the plotter API is about as simple as it can possibly be --
it's a very cut down and situation-specific variant of any vector
graphics drawing API.

Secondly, the plotter API has been stable for 6 months and, before that
(ignoring trivial const-correctness changes) for approximately 2 years.
It also has multiple successful implementations. 

This really doesn't indicate in any way that the plotter API is either
difficult to implement or a great maintenance burden. 

Additionally, when the most recent set of major changes to the plotter
API were made, we went out of our way to ensure that platform frontends
were not irrevocably broken. Certainly, we didn't quite succeed here,
but I'm pretty certain that the remaining minor fallout did not cause
frontend maintainers any great amount of pain.


J.


Reply via email to