NetSurf AGA optimizing

[Thorham]

To PeterK:

Why don't you use tables for this? It's faster than those loops.

[PeterK]

But the code is really simple, not even optimized yet ...

Yes, I know that I could replace the 3 loops with 3 tables,
... but first, I was too lazy and just wanted to see the results of this method,
...and second, these loops are only passed 3 times on average, thus the benefit of using tables is very small and requires 768 bytes of additional memory.

Btw, the color components in my code example are not exactly equally weighted atm, blue is pushed up and red is reduced, but that can be changed again. The possible values are 20, 65, 110, 155, 200 and 245 now, moved a bit up to prefer the brighter colors in the cube, since "dark errors" are less visible.

[Thorham]

But the code is really simple, not even optimized yet ...

Originally Posted by PeterK

Yes, I know that I could replace the 3 loops with 3 tables

That's very true.

Originally Posted by PeterK

...and second, these loops are only passed 3 times on average, thus the benefit of using tables is very small and requires 768 bytes of additional memory.

Btw, the color components in my code example are not exactly equally weighted atm, blue is pushed up and red is reduced, but that can be changed again. The possible values are 20, 65, 110, 155, 200 and 245 now, moved a bit up to prefer the brighter colors in the cube, since "dark errors" are less visible.

You might be able to do the weighting in the palette directly, by generating it weighted. That combined with using tables for getting the color will be a lot faster. Something like this (excuse any errors, didn't check this):

    lea     argbImage,a0
    lea     argbImage_END,a5
    lea     indexedImage,a1
    lea     redTable,a2
    lea     greenTable,a3
    lea     blueTable,a4

    clr.l   d0
    clr.l   d6      	; index color 0
    moveq   #70-1,d7	; alpha lower than 70 check

.loop
    cmp.b   (a0)+,d7
    bls     .isAlpha

; not alpha
    move.b  (a0)+,d0
    move.b  (a2,d0.w),d1
    move.b  (a0)+,d0
    add.b   (a3,d0.w),d1
    move.b  (a0)+,d0
    add.b   (a4,d0.w),d1
    move.b  d1,(a1)+
    cmp.l   a0,a5
    bne     .loop
    bra     .exit

.isAlpha
    move.b  d6,(a1)+
    addq.l  #3,a0
    cmp.l   a0,a5
    bne     .loop
    
.exit
    ...
    ...

[PeterK]

using tables for getting the color will be a lot faster

LOL
No sorry Thorham, but I would doubt that you will be able to notice any speed increase in a browser by saving a few CPU cycles with your tables. And regarding the code that you want to combine with your tables, you missed the fact that this code pushes the RGB level of every 2. pixel in order to get some sort of very primitive dithering by adding "noise" (which cannot be moved into the tables). And also the black and white handling can't be done with the tables since it detects the combined RGB values and not the componebts seperately.

[Thorham]

To PeterK:

I've tried some things and came up with a little something. It's in The Zone (render24bit.zip).

It contains a source code, render24bit.s (and meynaf's c2p which is included by the main file, don't worry about it), which should assemble with PhxAss with the M=2 option. Personally I use AsmPro for these test programs. Just make sure to set the include paths in the source code. There are two. One for the system includes (I've used the includes from the archive you sent me) and one for the FULL path of the directory the source code is in (annoying, I know ).

I've also included some BMP pictures to use with the program. Set the name of the BMP file you want to use close to the bottom of the source (also annoying ). If you want to use your own, make sure they're 640x512 pixel 24 bit BMP files.

The program uses a 6x6x6 palette, and uses tables for color conversion and clamping of dithering values (one table per gun color). The dithering is really simple and quite effective. And do play with the dither value. I think 16 may be optimal.

[PeterK]

Actually, they seem to be more than twice as fast.

Yes, it could indeed even be more than twice, but don't compare the time for the color reduction only, compare the speed of the browser displaying complete web pages. The speed of the browser depends on many other routines too. That will cause these peephole optimizations always have a limited effect as soon as the related code is not the bottleneck anymore.

It can if white and black are part of the 6x6x6 palette.

Not in my palette, because black and white are overlapping the "MiniCubes" of the other palette colors, and thus black and white have to be assigned first. My color components don't start with zero or end with 255. Their values are 20, 65, 110, 155, 200 or 245. Black and white are the system colors (pen 1 and pen 2).

Thorham, please also upload some of your resulting images. I'm a bit too lazy now to start playing with your code, but I will try to do that later.

[Thorham]

Originally Posted by PeterK

Yes, it could indeed even be more than twice, but don't compare the time for the color reduction only, compare the speed of the browser displaying complete web pages. The speed of the browser depends on many other routines too. That will cause these peephole optimizations always have a limited effect as soon as the related code is not the bottleneck anymore.

These are very small tables. In your icon.library trying to save memory makes sense, because it's useful on low memory systems. This browser, however, doesn't run on such systems, so it's not an issue. The tables I'm using now handle color reduction and clamping to the maximum value in one table per gun color. This means you can dither and adjust brightness levels (I'm going to add to that so you can reduce the brightness, too) and not need extra code to handle clamping.

Also, when optimizations are done in other parts of the browser code, it all adds up.

Originally Posted by PeterK

Not in my palette, because black and white are overlapping the "MiniCubes" of the other palette colors, and thus black and white have to be assigned first. My color components don't start with zero or end with 255. Their values are 20, 65, 110, 155, 200 or 245. Black and white are the system colors (pen 1 and pen 2).

Nertsurf calculates a palette per page (from what I've read), so using a straight 6x6x6 palette shouldn't be a problem.

Originally Posted by PeterK

Thorham, please also upload some of your resulting images. I'm a bit too lazy now to start playing with your code, but I will try to do that later.

Sure, although trying the program is better The left one is with dithering, the right one is without.



Turns out that the dithered image is too bright, which I didn't see on my SVGA CRT monitor whose gamma is on the dark side. I'll see what I can do to solve that (stick gamma correction into the tables perhaps).

Edit: Brightness problem solved. Dithering happens around a value now, instead of above a value. Took only one extra instruction.

[PeterK]

@arti
Finally, I tried to write my 676 palette code down in C, but without ever compiling it and not optimized with tables as suggested by Thorham. Maybe someone who has successfully compiled Netsurf already could try to merge my code into the sources by using the new "cube_676_palette" instead of the default one. Please forgive me if I made some mistakes in writing untested C code:

[NovaCoder]

Hiya,

Thanks for your efforts Peter

Unfortunately only Arti can compile this monster, I tried myself and failed miserably

Hopefully Arti will try and implement these changes into NetSurf AGA soon.

[PeterK]

Update 2: My first update was probably the wromg way to fix the palette generator.

After thinking it over again I believe now that I've merged the function declaration and the function call into just one piece of code before, which won't work.

So, now I'm trying it again:
1. step = the palette generator declaration and ...
2. step = calling the function:

nsfb_palette_generate_cube_676(struct nsfb_palette_s *cube_676_palette);

[Thorham]

I posted a method that's fast and dithers the image, I don't see the problem with some small tables. What you're doing is only slowing things down to save a few KB. What's the point?

As I've said before, there isn't a whole lot of room to work with here. You use tables, or you're going to end up getting the same speed as HAM8 rendering.

[PeterK]

Now it's going to be slower than rendering in HAM8

Oh, I didn't know yet that Netsurf is already rendering in HAM8. Arti didn't tell me about that. So, why am I wasting my time here ?

Thorham, I didn't say that your tables shouldn't be used, but first, it's more important for me to get my code to run at all, then we can talk about performance tweaks.

If arti prefers your HAM8 rendering code then it's his decision and I will accept that, no problem!

[Thorham]

Originally Posted by PeterK

Oh, I didn't know yet that Netsurf is already rendering in HAM8. Arti didn't tell me about that. So, why am I wasting my time here ?

You're missing the point. If you're at the point where you're doing things at HAM8 rendering speed, then you might as well have the browser run in HAM8, and that might be a simple as simply opening a HAM8 screen instead of a 256 color one. SDL AGA is supports 8 bits per pixel, so it's probably no big deal to get this to work properly.

[PeterK]

Sorry, but I have no experience in writing HAM8 code. I can only offer a solution which I'm able to code. If you have a better solution then your code will make it.

[Thorham]

Originally Posted by PeterK

Thorham, I didn't say that your tables shouldn't be used, but first, it's more important for me to get my code to run at all, then we can talk about performance tweaks.

Okay, that makes sense.

Originally Posted by PeterK

If arti prefers your HAM8 rendering code then it's his decision and I will accept that, no problem!

Well, it wouldn't hurt. A HAM8 browser would sure be nice. Much better than any fixed color solution will ever be. Btw, it's meynaf's code, not mine Can't be looking like a lamer, now can I

Originally Posted by PeterK

Sorry, but I have no experience in writing HAM8 code. I can only offer a solution which I'm able to code. If you have a better solution then your code will make it.

Perhaps NovaCoder can offer some insights about HAM8 and SDL AGA, although he believes it's not possible, which I don't believe

Anyway, the program I uploaded for you to try contains a fast method with dithering. Did you check the images I posted a few posts earlier? The dithered image is too bright, but that's solved (the fixed version is in the archive I uploaded to The Zone).

[PeterK]

Thanks for the updated package. I regret, but I didn't do anything the last few days.

I know the same problem with the brighter image from my own code and fixed that too. The dithered image that you uploaded here looks not better IMO than the results from my current 676 palette code that I posted today.

[Thorham]

Originally Posted by PeterK

I know the same problem with the brighter image from my own code and fixed that too. The dithered image that you uploaded here looks not better IMO than the results from my current 676 palette code that I posted today.

I was still using a 666 palette there. Could you post an image (including the original)?

[PeterK]

Ok, it's in the zone. But please remember that all images are in reduced size (256 pixels max width)

[Thorham]

Thanks

I'll change my code to do 676 and compare the results.

[NovaCoder]

If I were you guys, I'd wait until Arti responds to this thread before taking this any further.

As I mentioned above, I cannot build NetSurf so I cannot test any optimizations myself unfortunately

The AGA SDL which NetSuf is built on only support 256 color AGA displays and so it will not support HAM8 without making changes to the SDL library.....please be my guest if you want to prove me wrong

I'd have thought rendering speed should be given priority over quality so why are we even discussing HAM displays?