@ Mrodfr

Google has a string box on the page, meaning that it will flash the cursor all the time...

@ cass

Update 4 installed ? Crash-on-exit points to an old elf.library that would crash if shared objects opened shared objects themselves.

@ magic

The frequent security warning popup is usually a sign of a wrong clock setting. Make sure your clock is set to the correct date, or almost every security certificate will have expired.

It's slower than the alpha because it does not share any code with the alpha, it's completely rewritten, and does not contain any hardware acceleration (the alpha did contain hardware acceleration for some parts).

I think I mentioned it often enough that this is an early version and that the current focus is on stability and completeness, not on speed.

@ RacerX

Font sizes for the user interface aren't changed yet. I guess I can use the font preferences settings. I'll see what can be done about it.

@ AmigaNG

No, "chrome" is FF's name for it's user interface.

@ all

Regarding bookmarks saving: This is done via sqlite. It uses record locking, so if the file system does not support that, it might be problematic. I used TW on a FFS partition, and for me, saving bookmarks worked.

Also worth mentioning is that the lack of a Level 2 cache is probably the cause for the slow speed on the 440. Not much we can do about it, we'll see if the hardware acceleration will change anything (it should).

Copy&Paste isn't implemented yet

100 % CPU load should usually only appear when a page is updating (GIF anims, dynamic HTML etc). I'll check if the code allows me to add an idle measurement and drop the frame rate of updates depending on the cpu load.

And yes, the easteregg is the dynamic html boing demo

Speed on Sam440:

I assume the missing level 2 cache on the 440s will have a big impact on rendering speed. TW basically performs better with higher memory bandwidth.

Whether there is CPU load after loading the page or not also depends on the page that is shown, since some pages have scripts running or animations. I also think that there's constant database activity.


hardware accelerated rendering:

The Firefox codebase provides a backend for acceleration through OpenGL. Sadly, MiniGL isn't up to the task. Therefore, this sort of acceleration will be available with Gallium in one of the next AmigaOS releases.

We are also looking into writing our own layer manager for TW using the compositing engine of AmigaOS 4.1. I have no idea, though, how complex this task will be, as I haven't looked into that code yet.


Also, as Rogue already said, the updates are currently merged into one big box. That means, if there is a loading animation in the top right, and a progress bar in the lower left, the whole screen will be redrawn since both rectangles will be merged into one. Future versions will use a smarter algorithm for merging boxes that try to minimize the amount of redraw operations and at the same time keep the area of redraw at a minimum.

Quote:

Yes, I ran into this one as well. I guess I know what it is, will be fixed in the next version.


Quote:

I think you can click on options in the yellow bar and prevent it from doing this, but the whole process is defined by Firefox itself, so no way to change that behavior.

You might try about:config and see if there's any advanced option you can use for this.

Quote:

Yes. The current version does not yet support threaded tabs. In a future version, tabs will each run in it's own thread, which will balance the load.

Regarding speed:

As I wrote in the readme file, it's not "meant" to be fast. It is simply doing software rendering. We're currently going for stability and completeness.

For example, there's some problems with tab titles disappearing, as well as some refreshes being swallowed up. This is much easier to track and fix in a software only version. Once the software only version renders correctly in all aspects, it's possible to go for an accelerated display.

This release is mainly meant to gather user experience. It is by all means a usable browser already, though it will still need speedup.

I tested it on a Pegasos II and X1000, and on the former, it's ok, and on the latter, it's actually quite good (should be expected, I guess).

Quote:

That's the way Mozilla creates windows. It creates them with a 0 by 0 size and then resizes them. A bit strange, maybe, but I consider it a minor issue. AmigaOS can not create 0 x 0 windows, so I need to create a 1 x 1 (inner width) window and that includes the decoration already. I might at a later point hide windows with 0 size until they are resized to their nominal size.

The startup time is partially due to the large amount of code it loads. It opens libxul.so, which is IIRC some 40 MB and contains all the core functionality of the browser. Also, the startup of the font backend takes some time. We're looking to alternatives for fontconfig, but that includes writing a new font backend for cairo...

Next version will feature a splash screen to show that things are moving.

Quote:

I noticed that as well, but I have no idea why yet. I haven't looked into it yet, though.

Quote:

I guess this is basically the same as the missing tab titles. Maybe some updates are swallowed...

Quote:

Didn't actually try that. I think file access should work, in general, and downloading addons via the addon page does work, so it might be the file requester that is acting up.

Quote:

We do want to set up a bugtracker soon. No idea how we are proceeding with it, I'll check out os4depot's bugtracker.

By the way, no one found the easteregg yet ;) ?

Yes

For those interested, there is a new update about Timberwolf on Amiga Bounty

Just to dispel the rumor I just heard:

If someone tells you Rogue and me no longer work for Hyperion, he's talking bull.

Thanks.

For those wanting to see TW in action, check the frontpage

One thing I would like to add:

- It's NOT used Mac hardware

Regarding the video replay: Yes, it's slow. We'll see what we can do. I wouldn't expect miracles, though, since I have a 2 GHz Intel notebook that also can't play anything but 360p decently.

I'm watching TenFourFox but right now, I'm not willing to embark on JS optimization yet. First, I want to finish the browser, then see about adding features and optimizing it. Stable code basis, then branch out. Anything else will lead to nightmare testing and hard to track bugs.

As such, there will most likely not OpenURL support in it at the beginning, although that is sufficiently easy to add.

TenFourFox did not make the JS engine, they fixed the JIT for PPC, afaik.

Oh, and forgot to even mention: It's updated to Firefox 4.0.1 source code now

Quote:

I have 512 MB in my Pegasos, and it still works without resorting to paging, even on big pages. I don't know what the exact memory footprint is, but I think it is comparable to the Linux version.

Quote:

I don't think we'll add it to an alpha version, but it's something that I do want to implement. Firefox does support the use of custom menus (Mac versions need this). However, the menus need to confirm to certain standards, like being able to show custom images and nesting depth. The former is possible with Amiga Menus, but I'm not sure about the latter (it's been ages since I've last written more complex intuition code).

In general, I want as much Amiga-specific features as possible.

Quote:

See my other post, it's comparable with MUI OWB. I test it on the Pegasos, and with an optimized build, it's perfectly usable. I have not tried it on a Sam yet, I'll have to check. And I know someone who will surely test it on his BlizzardPPC :|

The drawing code has changed substantially between 3.x and later versions. This is reflected in Timberwolf as well, none of the original drawing code remains in 4.0 (except the mouse pointer handling code).

As rogue said, the HTML renders correctly. Same applies for dialogs (preferences, error console and the like). Popup windows, like the menus and some of the hint boxes, are sometimes rendered empty (window opens, but there is no content). Unfortunately, this works when I do a debug build (but the debug build is far too slow to be usable, the optimized build is about ten times faster). This is something I will be looking into later.

Speedwise, you can compare it to the MUI OWB for OS4. In some areas, it's actually a bit faster (when lots of "complex" graphics are rendered, like, lots of transparency and blending going on). Scrolling is faster on OWB, but as I said earlier, the current Timberwolf does not use any hardware acceleration, but basically just draw in back buffer/blit to screen (although it does of course only blit damaged regions). However, it is not jerky, it's perfectly usable, and I expect it to be really smooth once I rewrite the layer manager in TW4 to use hardware compositing.

The new TW4 rendering now also uses a new method of propagating screen updates. The original one used intuiticks to cope with asynchronous updates. The new one passes messages around to inform of updates in the graphics output, and thus, when the page is fully rendered (and no animation is going on), the CPU load drops to zero.

After a bit of downtime, I've gotten around to upload a new screenshot and make a small update over at amigabounty.net.

We're closing in on a new test version. Still a bit of tweaking to do, but it's looking quite good in the meantime. Currently, only software compositing is supported, but it still is usable (it's actually better than the original 3.5 release).

Stay tuned

@all

Can we stop quoting benchmarks until the thing actually works ? For all you (and me) know, it might be drm that's slowing it down, or kernel switches, or bad weather.

Geez, sometimes, I really don't get it. Sorry.

Edit: Should learn how to spell correctly one of these days :|

@LiveForIt

Quote:

r0 can never be used as an address, it will always be 0 when used in such a way.

To ensure that a register is taken that works as a memory address, use the "b" constraint. Also, for memory references themselves (as in the lwz), you can use use "m".

Finaly, stwbrx is defined as

stwbrx rs, ra, rb

and the effective address is (ra|0)+(rb), so the code can be compressed llike this (since r0 is automatically used as constant 0, no need to load an additional register with it):



Note that this also adds r3 to the globbered registers, meaning that their value is undefined after the asm statement (otherwise, the compiler might assume that r3 wasn't change, which it was).

You might want to check if this works better for you.

@abalaban

What's wrong with pthreads ?

@tommo1975

"Incredibly loud set of fans" ??????

I don't know what they were hearing, but I have the machine here, and I know that it's totally silent. I have to look at the debug leds on the board to determine whether it's on or off...

Sorry, in a time where PC's actually NEED a water cooling to be endurable, this is ridiculous...