English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.Apps

 
 
Thread Tools
Old 14 May 2016, 23:09   #1
Leandro Jardim
Registered User
Leandro Jardim's Avatar
 
Join Date: Nov 2009
Location: Legoland
Age: 38
Posts: 1,150
How to fix Netsurf 3.5 corrupted images?

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.
Leandro Jardim is offline  
AdSense AdSense  
Old 15 May 2016, 00:44   #2
utri007
mä vaan
 
Join Date: Nov 2001
Location: Finland
Posts: 652
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.
utri007 is offline  
Old 23 May 2016, 01:00   #3
Leandro Jardim
Registered User
Leandro Jardim's Avatar
 
Join Date: Nov 2009
Location: Legoland
Age: 38
Posts: 1,150
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.

Last edited by Leandro Jardim; 23 May 2016 at 06:05.
Leandro Jardim is offline  
Old 23 May 2016, 14:22   #4
utri007
mä vaan
 
Join Date: Nov 2001
Location: Finland
Posts: 652
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.
utri007 is offline  
Old 23 May 2016, 22:19   #5
Leandro Jardim
Registered User
Leandro Jardim's Avatar
 
Join Date: Nov 2009
Location: Legoland
Age: 38
Posts: 1,150
Thanks for the feedback. Wow, the Amiga really needs a modern browser, even the Atari ST has NetSurf, if I am not worng.
Leandro Jardim is offline  
Old 24 May 2016, 00:18   #6
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by utri007 View Post
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)


Quote:
Originally Posted by utri007 View Post
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!
matthey is offline  
Old 24 May 2016, 00:38   #7
Retro1234
5150

Retro1234's Avatar
 
Join Date: Jun 2006
Location: Sycophantazia
Posts: 3,715
Quote:
Originally Posted by Leandro Jardim View Post
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.

Last edited by Retro1234; 24 May 2016 at 00:50.
Retro1234 is offline  
Old 24 May 2016, 01:06   #8
Leandro Jardim
Registered User
Leandro Jardim's Avatar
 
Join Date: Nov 2009
Location: Legoland
Age: 38
Posts: 1,150
Quote:
Originally Posted by Retro1234 View Post
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.
Leandro Jardim is offline  
Old 24 May 2016, 07:44   #9
utri007
mä vaan
 
Join Date: Nov 2001
Location: Finland
Posts: 652
Quote:
Originally Posted by matthey View Post
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


Quote:

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.
utri007 is offline  
Old 24 May 2016, 08:58   #10
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by utri007 View Post
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.

Quote:
Originally Posted by utri007 View Post
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 .

Last edited by matthey; 24 May 2016 at 19:32.
matthey is offline  
Old 24 May 2016, 14:13   #11
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 883
Quote:
Originally Posted by matthey View Post
Chris Hames
Chris Hodges..
wawa is offline  
Old 24 May 2016, 19:32   #12
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by wawa View Post
Chris Hodges..
Right. Fixed.
matthey is offline  
Old 24 May 2016, 21:06   #13
utri007
mä vaan
 
Join Date: Nov 2001
Location: Finland
Posts: 652
Quote:
Originally Posted by matthey View Post
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.
utri007 is offline  
Old 24 May 2016, 23:14   #14
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by utri007 View Post
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.

Quote:
Originally Posted by utri007 View Post
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.
matthey is offline  
Old 25 May 2016, 03:40   #15
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 883
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
wawa is offline  
Old 25 May 2016, 04:01   #16
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by wawa View Post
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:

Code:
#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.
matthey is offline  
Old 25 May 2016, 07:19   #17
utri007
mä vaan
 
Join Date: Nov 2001
Location: Finland
Posts: 652
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
utri007 is offline  
Old 25 May 2016, 21:30   #18
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by utri007 View Post
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.
matthey is offline  
Old 25 May 2016, 22:29   #19
utri007
mä vaan
 
Join Date: Nov 2001
Location: Finland
Posts: 652
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.
utri007 is offline  
Old 25 May 2016, 23:18   #20
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by utri007 View Post
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.

Quote:
Originally Posted by utri007 View Post
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.

Quote:
Originally Posted by utri007 View Post
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.
matthey is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
NetSurf arti support.Apps 440 Today 18:09
EmuCPC 0.7 - Corrupted graphics amigoun support.Apps 2 22 July 2014 16:10
17 Bit PD disks corrupted andyhants support.Games 0 29 May 2014 11:12
(Apparently) corrupted hard disk images Maren support.WinUAE 6 28 July 2011 15:57
corrupted partition Gavilan support.Hardware 10 04 April 2007 20:56

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 23:13.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.27416 seconds with 14 queries