We need an iBrowse replacement for 68k!!!

[chris]

Cool, we should be able to do a C2P straight to the main bitmap then for extra speed

If you mean rendering direct to the window, I've tried that and it gives all sorts of problems.  There's an option to enable it (I think.. or maybe I removed it again), but it's only there to aid debugging.

[chris]

Edit Final:

It looks like the freeze is from BltMaskBitMapRastPort() of gui_window_set_icon() from gui.c.

A0 = scrbm = 0x973a574
D0 = srcx = 0
D1 = srcy = 0
A1 = destrp = 0xa43b388
D2 = destX = 0x9e
D3 = destY = 0x14
D4 = sizeX = 0x10
D5 = sizeY = 0x10
D6 = minterm = 0xe0
A2 = bltmask = 0

It looks to me like the minterm and bltmask arguments are switched for BltMaskBitMapRastPort(). Is that what was fixed for the other BltMaskBitMapRastPort() in /amiga/plotters.c?

Yes, and I fixed it here too at the same time. http://git.netsurf-browser.org/netsurf.git/commit/?id=9ac9866521e48933389dcf05f1ec5523f36b3435

minterm is correct - 0xe0 looks about right (whatever "(ABC|ABNC|ANBC)" equates to)
I think the problem is that I've not accounted for bltmask being NULL.  I've fixed this now, and also in plotters.c.  New build up (this one appears to work without freezing up).

[itix]

It uses an offscreen buffer for rendering, which defaults to the same size as the screen.
edit: it's flagged as BMF_DISPLAYABLE so will be using chip mem, however it doesn't get displayed itself, only blitted to a displayed bitmap, so I might be able to remove this flag? (edit2: I've removed it and it seems happy on the OS4 build)

If you specify BMF_MINPLANES it wont use chip ram anymore. But without BMF_DISPLAYABLE is better for Netsurf.

Cool, we should be able to do a C2P straight to the main bitmap then for extra speed

If you mean rendering direct to the window, I've tried that and it gives all sorts of problems. There's an option to enable it (I think.. or maybe I removed it again), but it's only there to aid debugging.

Shouldnt it work fairly well with WriteChunkyPixels() (V40)?

[matthey]

With Os 3.9 and the shell from Os 3.9, it is "star less than greater than". Thus, "program "star less than greater than"foo" redirects the standard error to a file (or a device). Actually, it's in the manual. I wonder why so many people don't find the time to browse it for such questions.

I picked up and read my AmigaOS 3,1 manual that was sitting beside me. I don't know if wawa was using AROS (based on 3.1), UAE (probably with 68k AROS Vision knowing wawa) or AmigaOS 3.9. I only assumed the lowest modern (in Amiga terms) Amiga base. In a perfect Amiga world, all 68k users with a 68020+ would be using AmigaOS 3.9 and it would still be developed. Of course if AmigaOS 3.9 was still developed then the AmigaOS and Reaction APIs would be more similar to AmigaOS 4 and Chris wouldn't have wasted so much time adding AmigaOS 3 compatible code and I wouldn't have wasted so much time debugging it. It doesn't do any good to complain about it as that is not productive. Instead you see us doing it. Thanks for helping to provide the debugging tools to do it. I also understand that you are trying to be helpful and realize the importance of what we are trying to do here .

Yes, and I fixed it here too at the same time. http://git.netsurf-browser.org/netsurf.git/commit/?id=9ac9866521e48933389dcf05f1ec5523f36b3435

minterm is correct - 0xe0 looks about right (whatever "(ABC|ABNC|ANBC)" equates to)
I think the problem is that I've not accounted for bltmask being NULL.  I've fixed this now, and also in plotters.c.  New build up (this one appears to work without freezing up).

Startup completes here with no freezes or hits and displays the startup page! Good job! There are many different paths or areas to debug now but you may need to fix some things up first? Let me know what path(s) should be debugged first.

[chris]

Startup completes here with no freezes or hits and displays the startup page! Good job!

Wait... you're actually getting the NetSurf welcome page rendered on screen?  I mean this one?

There are many different paths or areas to debug now but you may need to fix some things up first? Let me know what path(s) should be debugged first.

I'm not getting anything rendered here and it crashes if I move the mouse.  Certainly the moving the mouse crash I'd like to fix, if it shows up for you?  Beyond that I can't really test it!  It won't run on my A1200 either - red screens at some point during startup.

[wawrzon]

@matt, thor
no, i was using my 3.9++ this time and since away from home have not had a manual at hand neither could find a definite answer on net, hence asked.

besides im not testing vision, usually im testing plain aros nightly or my own compile.

[wawrzon]

@itix

Does it only use Reaction for the gadgets outside the main window and just treat everything inside the main display area as a large bitmap?

does that apply to your netsurf 2 mui frontend as well?

[itix]

@itix

does that apply to your netsurf 2 mui frontend as well?

Yes it does. Main view is rendered to large bitmap and everything outside main view is using MUI. I even reused some Chris' code there.

Edit: or at least I think so. I might have just copypasted some parts because file headers have my name there only. But I recall Chris complained about it because I used his code without giving merit. If it is so, I am sorry =P

[woof]

>I don't think DoMethod is a stub - it's a real function[...]in the libamiga static link library.

See my Aminet/SimpleDT for a DoMethod implementation WITHOUT using libamiga

Alain Thellier

[wawrzon]

i am online now with netsurf and im posting here now from however the rendered sites look in many cases pretty messy. especially aorg. but the browser seems stable, if slow, but im running verbose option. screenshot follows.

edit: typos &screenshot:
http://www.amiga.org/gallery/index.php?n=3880

[matthey]

Wait... you're actually getting the NetSurf welcome page rendered on screen?  I mean this one?

Yes! This is the page I see although with a few more glitches. There were no more hits up to that point for me.

I'm not getting anything rendered here and it crashes if I move the mouse.  Certainly the moving the mouse crash I'd like to fix, if it shows up for you?  Beyond that I can't really test it!  It won't run on my A1200 either - red screens at some point during startup.

No problems here until I try to interact with something. It seems to be stable sitting there. I'll try again to see if it intermittently works.

[wawrzon]

this page looks alright here, though others do not as you might see on my screenshot attached. navigate to aorg to see a real mess.

No problems here until I try to interact with something. It seems to be stable sitting there. I'll try again to see if it intermittently works.

links and filling the forms works, though the browser isnt exactly responsive on uae, so it might make impression as it locks up on real hardware.i will mute the debug now and see how that works.

edit: looks like the webpages get plotted in four colors;)?? (at least when it comes to graphics, is there some planar code in the plotter?)

edit2: so, even with debug off the interaction like following links is still pretty slow here.

[matthey]

links and filling the forms works, though the browser isnt exactly responsive on uae, so it might make impression as it locks up on real hardware.i will mute the debug now and see how that works.

edit: looks like the webpages get plotted in four colors;)??

I was able to get through startup to the welcome page again (this time with no -v). Typing in amiga.org for the URL works but hitting return crashes for me with no guru or recorded hits. I have more gfx gliches than you wawa. It's possible that the slower speed on the real hardware is a problem but I wouldn't think so. The 68k code is really aweful, even for optimizations being turned off.

Code: [Select]

  move.l (a0),(a1)
   addq.l #4,a0
   addq.l #4,a1

instead of:

Code: [Select]

  move.l (a0)+,(a1)+

doesn't make debugging easier. There is a *lot* of room for optimization improvement.

[itix]

>I don't think DoMethod is a stub - it's a real function[...]in the libamiga static link library.

See my Aminet/SimpleDT for a DoMethod implementation WITHOUT using libamiga

We are splitting hairs but yes, DoMethod() is a stub. All it does is moving parameters to registers (A0, A1, A2) and then calling h_Entry.

Reason why it was moved to Intuition in OS4 was that now it had to figure out is hook pointing to PPC or 68k code. This approach didnt leave room for inlined or static link lib.

[chris]

edit: looks like the webpages get plotted in four colors;)?? (at least when it comes to graphics, is there some planar code in the plotter?)

No, nothing planar at all, it uses some graphics.library basic drawing tools to contruct the pages, and cheats a bit with datatypes.library to dither the graphics down for the screen.  Maybe that's the problem?  What sort of screenmode are you running in?  Can you try an 8-bit screen?

edit: Also I remember that I disabled the tiled bitmap renderer, which might account for amiga.org looking a bit dodgy (beyond the lack of colours thing).

edit2: so, even with debug off the interaction like following links is still pretty slow here.

Unfortunately I can't enable GCC optimisations due to the tag-trashing problem.  However I know there's some sub-optimal code there - such as using datatypes to scale and dither bitmaps, and outline fonts on OS3 are really slow so I could try a quick'n'dirty bitmap font renderer.  You'd lose support of characters outside ISO-8859-1 but the speed up should be significant.

[chris]

The 68k code is really aweful, even for optimizations being turned off. [...] There is a *lot* of room for optimization improvement.

If somebody can supply the relevant patches to get a working gcc4.5.4 or newer and prove it doesn't optimise taglists away, maybe we can resolve that?