How to fix Netsurf 3.5 corrupted images?

[Leandro Jardim]

Anyone know why some images (supposedly transparent PNGs) show very corrupted graphics on NetSurf Reaction window, and how to fix it on OS 3.9?

Greets.

[utri007]

Wich version you are using? Aminet or test release? Are you using FBlit?

For a general interest, wich CPU? How reliable it works? Do you get slowdown effect after few surfed pages?

You could also ask from developer, email from here http://www.unsatisfactorysoftware.co...dex.php?pg=who

Or write to amiga.org thread
http://www.amiga.org/forums/showthre...=70260&page=17

Chris needs any kind of feed back to make it better. He has got so few bug repoerts/feedbacks that he currently wonders is there any point to trying to solve remaining problems. He very nice and friendly guy, not like coders usually are.

He is not very experienced 68k coder, so he would need to help from somebody with debugging experience.

[Leandro Jardim]

Sorry for the late answer, utri007.

I was using the Aminet release, on WinUAE (040+FPU) with AmigaOS 3.9. Strange that you touched about the slowdown subject, I only noticed a minor slowdown with NetSurf, but thats very common with browsers even on some Windows machines.

That's too bad that chris is losing interest on it, him should have reasons for that. Please say to him I was very impressed by seeing the pages nicely renderized and the preferences dialogs now ready. My only issues are with transparent images like GIFs and PNGs. But unfortunately I cant help chris much because I dont code in AmigaOS.

EDIT: I was wrong. The real issues are with datatype image scaling and the Reaction gadgets which sometimes doesnt update correctly.

[utri007]

OK, this version is targeted to real amigas. Arthur's fork might work better with winuae.

Slowdown occurs only with real amiga, two first pages loads fast, after that speed decreases a lot.

Current test version uses guigfx.library and render.library, so no datatypes in future. Sadly this version doesn't work winuae at all.

But it is nearly as fast then iBrowse. Rendering site like this takes about 20 seconds, or even less. About 30%-50% faster rendering compared to using datatypes. AGA has some color problems displaying images currently. Graphics card users need to set friend_bitmap:1 manually to choises file.

[Leandro Jardim]

Thanks for the feedback. Wow, the Amiga really needs a modern browser, even the Atari ST has NetSurf, if I am not worng.

[matthey]

Originally Posted by utri007

OK, this version is targeted to real amigas. Arthur's fork might work better with winuae.

Slowdown occurs only with real amiga, two first pages loads fast, after that speed decreases a lot.

Does TLSFMem work on the Apollo core/Vampire accelerator? Has anyone tried it? The slow down could either be software related or hardware related. If the problem is hardware related, the slow down is likely to be much less on the Apollo core with TLSFMem. The Apollo core addresses the 3 most likely hardware slow downs while using TLSFMem.

1) Faster memory
2) Much larger CPU caches
3) Much faster BFFFO instruction for TLSFMem than 68060 (9 cycles on 68060, rumors are 1 or 2 cycles on Apollo core)

Originally Posted by utri007

Current test version uses guigfx.library and render.library, so no datatypes in future. Sadly this version doesn't work winuae at all.

But it is nearly as fast then iBrowse. Rendering site like this takes about 20 seconds, or even less. About 30%-50% faster rendering compared to using datatypes. AGA has some color problems displaying images currently. Graphics card users need to set friend_bitmap:1 manually to choises file.

IMO, the move away from datatypes is sad. Are you using a 68060? The picture.datatype is compiled with GCC using 32x32=64 instructions which are trapped on the 68060 (used for DivMagic similar to what I am doing here: http://eab.abime.net/showthread.php?t=82710). OxyPatcher/CyberPatcher/MuRedox should provide some speedup. It is pretty ignorant that we can't get a 68060 compiled version of the picture.datatype. It would be easy enough to do. A few assembler optimized routines and it could probably be much faster for all 68k owners too. Instead we spin our wheels some more as the current AmigaOS owners hold the Amiga hostage. New sources look like spaghetti code with all the #if instructions to support all the various Amiga flavors and workarounds. The 68k AmigaOS is not supported and trying to make modern software for it is too wasteful of developer time (at least my time). The fastest Amigas are emulated and, in a couple of years, I wouldn't be surprised if the cell phones emulate an Amiga faster than the overpriced handicapped PPC hardware. Amiga NoWhere. Only Amiga makes it impossible!

[Retro1234]

Originally Posted by Leandro Jardim

Thanks for the feedback. Wow, the Amiga really needs a modern browser, even the Atari ST has NetSurf, if I am not worng.

Any info on ST version? I think Amiga version is more advanced? and would ST version work on EmuTOS? also there was Netsurf(wrong think it was Netscape and iCab)for classic Mac68k but I don't think it was very good.

[Leandro Jardim]

Originally Posted by Retro1234

Any info on ST version? I think Amiga version is more advanced? and would ST version work on EmuTOS? also there was Netsurf(wrong think it was Netscape and iCab)for classic Mac68k but I don't think it was very good.

Certainly AmigaOS version is more advanced. Netsurf for Atari ST is at version 2.9, while for AmigaOS it is at version 3.5.

This is the link for the last version: http://www.netsurf-browser.org/downloads/atari/
This is the link for the Atari ST development group: http://www.atari-forum.com/viewtopic.php?t=20443

Greetings.

[utri007]

Originally Posted by matthey

Does TLSFMem work on the Apollo core/Vampire accelerator? Has anyone tried it? The slow down could either be software related or hardware related. If the problem is hardware related, the slow down is likely to be much less on the Apollo core with TLSFMem. The Apollo core addresses the 3 most likely hardware slow downs while using TLSFMem.

1) Faster memory
2) Much larger CPU caches
3) Much faster BFFFO instruction for TLSFMem than 68060 (9 cycles on 68060, rumors are 1 or 2 cycles on Apollo core)

Apollo core doesn't have FPU and current builds needs that. By the way, TLSFmem doesn't work with Apollo 68040 accelerator.

Here is last build without fpu requirement

http://homepage.ntlworld.com/cdyoung...rf_os3_old.lha

IMO, the move away from datatypes is sad. Are you using a 68060? The picture.datatype is compiled with GCC using 32x32=64 instructions which are trapped on the 68060 (used for DivMagic similar to what I am doing here: http://eab.abime.net/showthread.php?t=82710). OxyPatcher/CyberPatcher/MuRedox should provide some speedup. It is pretty ignorant that we can't get a 68060 compiled version of the picture.datatype. It would be easy enough to do. A few assembler optimized routines and it could probably be much faster for all 68k owners too. Instead we spin our wheels some more as the current AmigaOS owners hold the Amiga hostage. New sources look like spaghetti code with all the #if instructions to support all the various Amiga flavors and workarounds. The 68k AmigaOS is not supported and trying to make modern software for it is too wasteful of developer time (at least my time). The fastest Amigas are emulated and, in a couple of years, I wouldn't be surprised if the cell phones emulate an Amiga faster than the overpriced handicapped PPC hardware. Amiga NoWhere. Only Amiga makes it impossible!

I ques that using guigfx / render libraries makes task easier and they are fast. I hope that somebody takes this task and continues Chris work. Chris will hopefully fix some bugs, so that remaining problem would be just slowdown effect.

[matthey]

Originally Posted by utri007

Apollo core doesn't have FPU and current builds needs that. By the way, TLSFmem doesn't work with Apollo 68040 accelerator.

TLSFMem is a good stress test of the BFFFO instruction (uses several variations). I wouldn't be surprised if well optimized TLSFMem dynamic memory allocations with fast BFFFO instructions could be 50% faster than the poorly optimized and slower algorithm AVL tree AmigaOS 3.9 allocations. Chris Hodges did a nice job with the TLSFMem implementation but wouldn't win many contests with his assembly optimization skills. My builitin.lib, DivMagic and eventually perhaps vbcc (if I can make DivMagic good enough) could be using the BFFFO instruction so I hope they fix the problem.

It looks like the 68k FPU has moved up in priority as it is planned for the next Apollo core release.

http://www.apollo-core.com/knowledge...=1108&z=9X-Xwb

It looks like they decided to go with the 80 bit FPU which should help compatibility and reduce the time needed to get it working. It also looks like the SIMD is up to 128 bits now and using the x86 SIMD ISA instead of PPC Altivec with CISC register/memory enhancements. I guess there is a lot more SSE code out there than Altivec especially with the PPC being dead so long. A-EON can't even bring to market a PPC with a standard FPU let alone a fancy feature like SIMD that 99% of general purpose home and on the go computers people use today.

Originally Posted by utri007

I ques that using guigfx / render libraries makes task easier and they are fast. I hope that somebody takes this task and continues Chris work. Chris will hopefully fix some bugs, so that remaining problem would be just slowdown effect.

So we stop using standard AmigaOS components because they are too slow, there are bugs and no support? We stop using full featured processors because they are too expensive? Just remember, only Amiga makes it impossible. Come on now, everybody sing along with the sadistic Amiga song .

[wawa]

Originally Posted by matthey

Chris Hames

Chris Hodges..

[matthey]

Originally Posted by wawa

Chris Hodges..

Right. Fixed.

[utri007]

Originally Posted by matthey

The 68k AmigaOS is not supported and trying to make modern software for it is too wasteful of developer time (at least my time). The fastest Amigas are emulated and, in a couple of years, I wouldn't be surprised if the cell phones emulate an Amiga faster than the overpriced handicapped PPC hardware. Amiga NoWhere. Only Amiga makes it impossible!

Amiga is hobby, that's why we are trying to solve problems wich doesn't have a sense.?

I have never interested emulators, hardware is only way to go. But that just me.

[matthey]

Originally Posted by utri007

Amiga is hobby, that's why we are trying to solve problems which doesn't have a sense.?

It makes sense to try to solve these problems but sometimes it makes sense to step back and look at the big picture. Even if NetSurf is fixed, it is likely to be a kludge of spaghetti code with #if and non-OS components only for the 68k. Compiler support for the 68k is unlikely to get better either without new hardware and new hardware is being greatly hindered by lack of OS support.

Originally Posted by utri007

I have never interested emulators, hardware is only way to go. But that just me.

IMO, an emulated market will always deteriorate and eventually die. Without affordable mass produced hardware, the Amiga is retro nostalgia only. I liked the interview with Jim Collas on how to bring the Amiga back. He stuttered and ummed for a long time when asked about the current Amiga business strategy but eventually mentioned mass produced affordable hardware and some new innovative technology (FPGA was not mentioned for some reason). I don't expect any 68k AmigaOS development until A-EON is done throwing good money after bad (Tabor) in hopefully their last attempt at affordable mass produced low end PPC hardware. I don't believe they want the competition from FPGA hardware. Instead of helping the Amiga 68k, it will be interesting to see if it is true that their business partner, Hyperion, is trying to buy out from under and extort the fledgling 68k market with P96. Grab the popcorn but don't hold your breath for any new 68k AmigaOS support or a good 68k NetSurf any time soon.

[wawa]

matthey, you again with your compiler metadiscussion mantra
sure, someone with appropriate background needs to talk to gcc guys about some issues. but i just thrown on my a4k with 4.6.4 compiled aros and its not that bad, considering its actually still bevor any optimsation

[matthey]

Originally Posted by wawa

matthey, you again with your compiler metadiscussion mantra
sure, someone with appropriate background needs to talk to gcc guys about some issues. but i just thrown on my a4k with 4.6.4 compiled aros and its not that bad, considering its actually still bevor any optimsation

I am primarily talking about difficult to maintain source code full of:

#if defined(AMIGAOS3)
<code>
#elif defined(AMIGAOS4)
<code>
#elif defined(AROS)
<code>
#elif defined(MOS)
<code>
#endif

It is ugly and difficult to maintain and debug. The code is usually broken for at least one target because nobody has all the target hardware for testing. Using non-OS libraries results in more of this. Lack of support and bug fixing for a target OS results in more of this. Poor 68k compiler optimization and code quality also results in more of this but it is only a part of the problem.

[utri007]

Matthey: Could you consider again if you could do some debugging to help Chris? Chris has high trust to your skills and he is not so familiar with 68k. You could contact him directly http://www.unsatisfactorysoftware.co...dex.php?pg=who

[matthey]

Originally Posted by utri007

Matthey: Could you consider again if you could do some debugging to help Chris? Chris has high trust to your skills and he is not so familiar with 68k. You could contact him directly http://www.unsatisfactorysoftware.co...dex.php?pg=who

I am not opposed to helping more but my priorities are with projects where I don't have to jump through hurdles and the result is more more likely to be a clear win. Debugging NetSurf is like looking for a small object in a hey stack. We don't even know if we are looking for a needle. I may have been lucky before that what I found was helpful. The "unofficial" Amiga GCC compiler is not supported and the 68k AmigaOS is not supported. Add on top of that the code needs to be fairly optimal for the 68k and the NetSurf 68k project has a high degree of difficulty which wastes developer time and increases the chances of unsatisfactory software.

[utri007]

I respect you answer, it just that I think that Netsurf is one of the most important 68k projects today and especially Chris' version. It most "standard" version, wich still uses mostly standard system libraries and it is "supported/accepted" By original dev team. What makes it most important is Vampire accelerators.

Have you tested current versions? Aminet version uses datatypes and test build guigfx/render library. Latter one has color problems with AGA and of course both of them has lots of minor and major problems. BUT they are both surpriginly fast.

And of course there are lots of importan projects going on, but this one Project wich interest all, not just developers. More users means more developers.

[matthey]

Originally Posted by utri007

I respect you answer, it just that I think that Netsurf is one of the most important 68k projects today and especially Chris' version. It most "standard" version, which still uses mostly standard system libraries and it is "supported/accepted" By original dev team. What makes it most important is Vampire accelerators.

I agree that a modern-ish web browser is one of the most important projects for the Amiga. It is right up there with a developed and supported AmigaOS which includes RTG, basic GUI components and datatypes included and semi-modern compiler support which gives reasonably good quality code. None of this is going to happen without affordable mass produced standardized hardware. We don't have good building blocks and we are building a house on sand without them.

Originally Posted by utri007

Have you tested current versions? Aminet version uses datatypes and test build guigfx/render library. Latter one has color problems with AGA and of course both of them has lots of minor and major problems. BUT they are both surprisingly fast.

No, I have not tested the new builds of NetSurf but it is on my to do list. I am still not a fan of avoiding datatypes even if it is faster. The concept of datatypes was one of the great Amiga ideas. It allows using many different types of objects with minimal code needed. It needs to be extended with stream support and other functionality as well as optimized for the 68k (picture.datatype especially). I would rather not build than build a rickety spliced together with whatever house on sand.

Originally Posted by utri007

And of course there are lots of important projects going on, but this one Project which interest all, not just developers. More users means more developers.

I agree. But there are likely some people who do not want more 68k users and are willing to sabotage the Amiga developers and users who do. As I have said before, it is not obvious who the bad players are as we have seen lately. I don't expect any change in the situation until the good money is finished being thrown after the bad and that could take years, if ever. The powers that be want more Amiga division and road blocks so we need to move away from the dependence on them but this also will take time.