NetSurf OS3.x Issues

[itix]

Hack = Add a feature to program wich original source doesn't have and woun't have.  SDL AGA is good example, Novacoder himself said it "quick dirty hack". There is no 8bit screen support in SDL and never will be.

Eh, SDL supports 8-bit screens. Only problem is that many games want hi/true color screens.

Of course coder can take a opensource code and make a changes to it, make it "his own". But future updates are not that easy implement any more. I'm not a coder that true, but I work with coders and seen problems wich are made By making unsupported features to original opensource code.

It depends on what you do, where and how. Graphics stuff is isolated to its own Amiga native backend and if properly implemented it is easy to maintain (I havent seen SDL AGA code). At the moment there is no Amiga code in SDL source repository. It was removed some 10 years ago but Amiga backends are (were) maintained separately.

[itix]

OK then I don't remember correctly why Novacoder calt his SDL AGA a dirty hack

Itix: Could you considering to help Chris? I do know that you don't have experience or interest with Reaction, but problem is elsewhere. Screen is not refreshed propely, etc.

Some years ago you said that you have considered to make 68k version of your netsurf MorphOS port.

I'd like to help but I really lack both time and motivation as I dont have 68k machine here. I have tried to port few of my programs to 68k but they have stagnated...

[itix]

Question is what size of memory chunk is common for NetSurf, how many chunks are in play, how large they are. If you have not yet implemented it, you might want to add a memory allocation debugging layer and collect statistics for it over time.

It may be worth investigating how the NetSurf memory allocations could be handled by an application-specific, custom memory allocator that sits on top of what malloc()/alloca()/realloc()/free() can provide and which should offer better scalability.

I would just take a shortcut and install TSLFmem: http://dump.platon42.de/files/

Other than that, there is no really solution. Designing good memory allocator is an art of its own where one has to consider memory fragmentation, allocation performance and deallocation performance.

Yeah, I read from previous page that with TLSFmem Netsurf is crashing but this is very likely due to internal memory trash somewhere in Netsurf... with good old memory lists and standard memory pools buffer under/overflows often go unnoticed but with TLSF you are likely going to crash right away.

Of course, Wipeout session could reveal this albeit it is going to be painfully slow experience with such a complex application.

[itix]

tlsf memory is too a bad memory allocator, because it is best fit. this give lots of cache misses, so all slow down. tlsf memory is more for realtime dsp systems which use no caches and it is important to have constant allocate time and no mem fragmentation
 i know years ago, that ixemul is the fastest lots faster libnix and clib2. so i furtherdevelop ixemul. many bash against ixemul. thanks to the work of Arti we all know  the confirm now. On my system too ixemul is lots faster

Ixemul has better memory allocator but ixemul.library is not safe from application using native Amiga API.

[itix]

i have never understood whats not safe about it..

To my understanding it is use of tc_SigExcept and Exec exception handlers. I dont havei nterest to fully analyze what ixemul is doing there but it seems it is used to catch CTRL-C and abort program execution immediately. If you are not prepared to that memory leaks can occur. If you are not prepared to that and you are executing critical OS call you crash and burn. It can be fixed by disabling signals before making an OS call, at least ixemul is internally disabling signals when making such OS calls.