duktape error NetSurf OS3

[chris]

Another new version.  Curious this time as to whether JPEG decoding speed is any different.

[chris]

040 and AGA loads amiga.org 27 seconds now,  that is big speedup. Was about 35 seconds.

Great!

Cache native versiona is now auto ON with AGA?

No, but I had broken the "scaled" cache option so that is working again.  Unless I've broken it in the other direction, but I don't think so.

060 and RTG seems 2 seconds faster, but that kind of speedup / slowdond can be just a tolerance.

It may be that what I've changed isn't relevant for the '060.

[chris]

chris, wouldnt that be best to get rid of the warnings first? who knows if these dont let the duktape work.

Yes, there's a ton of warnings Most of them are because of Gadget*/Object* definition changes in OS4. It's possible there's some genuine error hidden amongst them, but there are hardly any warnings when building for OS4.

even though it might be some endian issue as with webkit. does that currently work on ppc?

Yes.

I did have to add ppc-amigaos support to Duktape initially, but 68k doesn't complain and there have been a lot of configuration changes since then. It's possible something is misconfigured in Duktape (their website says it works on Amiga m68k with VBCC)

[chris]

Duktape works in my ixemul version.
I haven't tried with libnix yet.

Have you tried it with clib2?

[chris]

Yes, it has not compiled but it has with libnix.

It doesn't compile or it doesn't run?

[chris]

Sorry, doesn't run. Same error :

FATAL 56: uncaught error
PANIC 56: uncaught error (calling abort)
Abnormal program termination

OK, that's what I get too.  It looks like that output is from Duktape, so obviously clib2 is doing something it doesn't like.

Really needs somebody to trace Duktape to see where it is failing.

[chris]

this is second time clib2 causes a significant issue. which wont be traced let alone fixed, i fear. so why not simply build against libnix? may be a naive question, but what does clib2 offer in comparison?

The other "significant issue" isn't actually fixed by using libnix, so this is the first one only.

clib2 is more modern and supported.  libnix still uses ancient functions like Allocate(), I'd rather not go back to that.

Like the EU, we should stay in and fix the problems, not abandon it and change to something older which isn't necessarily better.

Next step is to enable DUK_USE_DEBUG and see what we get.

[chris]

my impression was that the gradually increasing lag occurs only with clib2, not libnix?

Because clib2 uses memory pools, libnix does plain allocations.  The slowness in clib2 occurs because after a while, memory pools aren't any more efficient than plain allocations.  Switching to libnix just means it will be that slow speed all the time, which isn't really a fix.

it may be more modern or not, but the question is, if it really is supported. who is maintaining this for amiga-m68k?

Olaf (olsen).

ok. i stand by as im not able to test the binaries currently.

I'll try it when I get chance.  Actually I might ping DNADL a note as it'll most likely get tested quicker.

[chris]

It's 1am so I'll worry about the rest later, however:

if you tell me where in the build scripts or headers the copmpiler options are specified i could try to compile it and post binary somewhere for people to test. the libraries/deps need to be recompiled as well i take it?

There's a Duktape config header file somewhere in content/(fetchers?)/javascript

[chris]

i see only /dev-netsurf/workspace/netsurf/content/handlers/javascript/duktape/duk_config.h

but i do see there only general platform flag m68k (DUK_F_M68K) no mention of particular cpu target. must be somewhere before. will keep looking for that.

That's all there is, Duktape doesn't care what sort of 680x0 you have, why should it?

duk_custom.h is where the lines should be added:
#define DUK_USE_DEBUG
#define DUK_USE_DEBUG_LEVEL 0

However I'm not getting any extra debug, so there's something wrong somewhere (DEBUG_LEVEL goes up to 2... still nothing)

[chris]

Oh, I didn't see all these messages ! I don't know I didn't receive any notifications about that, so sorry not answering you before !

Your email is very intermittent.

I have a similar problem with another thing. I try to maye NetSurf work on Happiga, an AmigaOS distribution (ARM4UAE-based) for the Raspberry Pi. I manages to install it but I can't launch it because the usergroup.library is missing. If you have an idea solving this problem, I would be happy to know it ! ^^

The short answer (which is on the email you probably haven't received) is to grab it from the AmiTCP archive.

[chris]

Try setting your language to English in Locale - could be something wrong with the French Messages file.

[chris]

I just tried this. Well, I don't have the same issue but another, now ! ^^

OK, it's probably worth looking at the French Messages file and seeing if there is anything odd around the ToolButtons line.

Try disabling the disc cache. disc_cache_size:0 in Choices (in Users/default)

[chris]

Netsurf requires 8bit screen, so AGA is minium?

Actually it shouldn't care, run it on a 1-bit screen if you like.

Actually, my screen was setup like this (that was possible thanks to Picasso96) : UAE: 800x600 32bit RGBA. I don't know if it answers the question... I tried with a setup like UAE: 800x600 8bit, but it does the same for the pictures.

a) ARGB is preferred/expected. It shouldn't matter, but it might.
b) friend_bitmap:1 forces NetSurf's rendering bitmaps into the same format as the screen. If you're running 32-bit this will happen anyway.
c) Images are quantised using guigfx, you might want to try out the demos to see if they work as expected.
d) Depending on what you've done with your config, you might find NetSurf opens its own screen and isn't in the format you think it is.

[chris]

a) OK, I set the screen like this : UAE:1024x768 32bit RGBA (RGBA is the same than ARGB, I suppose); NetSurf is configured to have the same screen resolution.

Nope, ARGB and RGBA are different.
ARGB
RGBA

So, alpha pixels will be red, red pixels will be green, green pixels will be blue and blue pixels will be see-through (or not, I can never remember which way round it is)

I don't think NetSurf uses the pixel format directly, but if it does that's what you'll get.

b) I added this into the "Choices" file, but it doesn't seem to do something

Not unexpected.

c) I don't know how to do this, I'm going to check this out, but if you have a tutorial link, i would kindly accept it ! ^^

The demos are in the guigfx archive (or maybe the render.lib archive)

d) Logically, it is configured to have the same definition as the workbench. I checked and that's the case. But the funniest part is that the favicon is quite well displayed ! ^^

The difference is the favicon is plotted direct to the window, whereas the page content goes through an intermediate step.

Try adding direct_render:1 to your Choices. **warning**warning** this might be a **very bad** idea!  I'm not sure it works **at all** and certainly it never worked properly, but it might confirm if the extra step is the problem. **warning**warning**

You can also try fiddling with AMI_BITMAP_FORMAT in bitmap.h.  Maybe it ought to be 0.

Try some different combos and let me know what you get!

[chris]

AGA has some serious problems, but pictures tell more than 1000 words.

Can you try direct_render too?  Above warnings apply.

You might need to set the tile size to be the same as the screen.