I see mention of optimizing rendering. Being a non-expert, is this the most demanding aspect of a web browser? I assume it is. Would this function be considered the weak link for actual 68K hardware based web browsers? Natami should be quite useful here if its advantages can be leveraged into the equation.

Questions.... x11 libs without requirement to actually run x11 itself sounds like a cool thing. Is this a good direction to take with improved 68k browser? These libraries simply route x11 commands to original Amiga graphics chipset?

Any good teacher on this subject would be greatly appreciated, I would like to learn.

So SDL used as generic way to port and maintain this program then?

What is this about the fonts? What is freetype, pango? Being a non-programmer I am only familiar with old Amiga fonts, postscript, and TrueType via your AFA...

 
Typically you want to give the user some more feedback and you render the screen earlier even if the HTML might not be fully mapped and before all images are loaded.
 
 
 
 
 
Lets say the browser does throw in render events of the screen 1 time per second.
 
Then the calculation looks like this
  - Downloading the files take 2.0 secs
  - Mapping the HTML takes 0.3 secs
  - Decoding the images takes 1.5 secs
  -----
so far 3.8 seconds
  - Rendering the screen 4 times 0.3 secs = 1.2 seconds
 
Total:
5.0 seconds
 
 
 
 
 
What happens if the browser trows in more render events?
Maybe 3 times per second?
 
Then the calculation looks like this
  - Downloading the files take 2.0 secs
  - Mapping the HTML takes 0.3 secs
  - Decoding the images takes 1.5 secs
-----
so far 3.8 seconds
  - Rendering the screen 12 times 0.3 secs = 3.6 seconds
  - But during the 3.6 seconds of the rendering another 3.3 seconds of render events will be generated. This will now take forever.
 
Total Time:
  several minutes
 
 

Rendering on the 68k Classic amiga is not really that fast.
And the bus to the GFX card is a serious limitation.
If the Browsers throws in too many render events, then the system will eat all the performance doing screen display.
 
The Bus to an AMIGA Zorro or PCI bridged GFX card has a typical transfer rate in the range of 10 MB/sec.

A screen of 1024x768*32bit has a size of 3 MB.
This means you can max do 3 screen refreshed per second.
Doing 3 Screenrefreshes will take 100% system time.
 
 
A careful balance needs to be taken here not to slow down the system too much by too many refresh events.
 
This issue does not exists on the NATAMI by the way, as the NATAMI bus is much faster.

Some question the use of a scripting language and future developments of web technology press to use XRX, REST and XQuery technology.

i need this not.but its possible, the ffplay 68k have too a arex Port.So code can reuuse.

Only problem i see to save a current page to file.not sure how this is implement in netsurf.

to add a amiga GUI to a SDL program is also possible, or make out of netsurf SDL a MUI plugin.

because its not much work to change SDL(it was begin in 1.2.6) so that it can render to a given window and draw at coordinates and messages from the AOS window can then preparse and then send to SDL.

This part is *very* interesting. Next release will be very interesting! :)

You meant something like this right?

Can you explain this again?

How does NetSurf draw its content?
Does it directly draw to a HW surface?

The idea to buffer the surface on the GFX-Card to be able to use the Blitter for scrolling is very good.
 

The other thing is that CPU rendering to a HW surface is often a slower solution than doing CPU rendering to a Fastmem-Surface.
Especially in a browser type rendering a SW surface should be optimal in my experience.

 
The best idea is often to combine both tricks.
Let the CPU render to a Fastmem Surface, copy this to the HW.
During the copy any RGB/BGR swapping could be done for free.
 

Then the HW surface is used as buffer to do Blitter supported scrolling.
 
 
 

bernd afa wrote:

only problem here is that .. BGRA32 Pixelformat

 
This is fixed?
Surprising that this is fixed for a SDL application.
Typicaly most applications would support RGB and BGR...
Netsurf was not originally an SDL application, right?
 
But actually it does not matter - we could do the byteswap on the flight when Flipping the buffer from SW surface to HW.

I have some experience in browser rendering code (aweb..) and I have done several SDL based games. I don't know if any help or review in the SDL rendering is needed at all. But if you/they need a hand - I would be happy to help.
 

>hope artur and bernd will accept your proposition

no problem i do nothing on netsurf since months now.
but i think when make really a AOS GUI or update the MUI from MOS, better wait until netsurf team have the diskcache ready and the google of summer code from 2010 is in, so hope that the native system Part in future is not change lots as before.

when you look how many changes are done in SDL, to get it working with newest core, then you can see thats a fulltime (hobby job )ti get netsurf upto date.but somebody else on netsurf team do the sdl changes.

  nsfb_colour_t nsfb_plot_ablend_be16(nsfb_colour_t pixel,nsfb_colour_t  scrpixel)
     {
         int opacity = pixel & 0xFF;
         int transp = 0x100 - opacity;
   

2) Your pasted code has a "c" variable.
Was this a global variable?
 
 
 
 

wrote:

SDL have the problem that it truncate 2 bits when use BGR16PC Mode because C compiler do

 
  Yes, SDL always behaved like this.
  The color is not 565 but 3553 on AMIGA/with PC16 mode.
  But this is no problem if you do the blit on your own.
 
 
 
 
 
  I would like to understand how NetSurf creates its Screen.
 
  * A good practice is to have a Fastmem screen and render to this screen only.
  * You will copy this screen to a GFX Card screen from time to time.
  The copy can be optimized using "damaged rectangle management" then you don't need to copy the whole screen everytime but only refresh parts wich were updated.
 
  * For just Scrolling you use only the GFX Sceen.
 
  The advantages of the above are big.
 
  Rendering to the Fastmem screen is 10 times faster then rendering to a GFXcard screen.
  Reading from the Fastmem screen is magnitures faster then rendering to the GFXCard screen. So ALPHA will only ever work reasonable with such a concept.
  Also you can always work in ONE screen format fully independant of what the Workbench or GFX-Card is set to.
 
  On the Fast to GFX-card access you do the convertion on the flight.
  This you can optimize with inline assembly for example to be nearlys for free.
 
  The SDL-CPUBLit routine is not optimal fast anyhow.
  So by writing your own Blitroutine you egt more speed anyway.
 
 
  Bernd, I did not fully under how Netsurf does it currently.
  Its not doing it like this right?
  Maybe you can explain it again real quick?