Regarding sound: Yeah, YouTube is too slow, but then, I wouldn't really suspect a software solution to be usable. I'll see if there's anything I can do in terms of assembler optimization (the X86 version has a few AFAIK), so it might be usable.

What works quite well is the replay of sound streams like podcasts and sounds from Wikipedia (my testcase for sound replay)


CPU load: The CPU load is probably due to a high frequency "heartbeat" that executes all the time. I'm looking into it, I guess that since we're using the "combined" thread model that also supports "local" threads (implemented via setjmp/longjmp), this is responsible for scheduling local threads. However, the AmigaOS implementation uses only global threads (i.e. system level), so it should not be necessary. I'll see that I'll get rid of it.


Drag&Drop: This was somewhat of a challenge. The Amiga does not have a drag&drop protocol, so it had to be implemented from scratch, fully inside Timberwolf. A "sprite" like approach similar to workbench wouldn't work since it would require locking the bitmap, which would kill off the highlighting of drop targets or spring-loaded folders in the bookmarks. So I went for a transparent window approach, which might be slow on machines without hardware accelerated compositing. I'll check if there's a possibility to use placeholders that are simply empty box outlines instead of showing the full picture.

Simpsons: Uhm, no

For an example of a video that actually works quite decently on my Pegasos II, you might want to look at this article on Wikipedia (scroll down a bit, larger version is available by clicking the symbol below the video). Far from impressive, I know, but it's a start.

Quote:

Yes, I do

I just uploaded a new beta version of Timberwolf to OS4depot.net (it popped up in the upload queue already, so if you want to grab it early, go get it).

Besides bug fixes, the new version implements some major new features:

- Drag & Drop support (customizing, bookmark sorting)
- Clipboard support (text only at the moment)
- Sound support (can now play video and audio streams)
- Some internal changes. NSPR threads completely rewritten to cope with NSPR's pecularities of condition variables.

The latter change is pretty fundamental, and even though I tested it substantially, I'm interested in seeing how it performs. Therefore, please report freezes or similar hangups as well, resp. add your findings to an existing bug on our bugtracker.

As always, donations are welcome on AmigaBounty.net (Click me, I'm a magical link)

IMPORTANT: Please also read the readme, it looks pretty and contains some vital information regarding the bookmark saving.

Have fun

The random numbers are needed for GUID creation. We use the new RANDOM device since it uses a real entropy collector for the random data, not pseudo-random numbers.

Regarding the storing of bookmarks: If you are unable to save bookmarks, make sure the "RANDOM:" device is mounted. Either add "mount random:" to the Timberwolf script, or move the file RANDOM from workbench:Storage/DOSDrivers to workbench:DOSDrivers. You might need to delete the profile directory again, or at least the file "places.sqlite" in your profile directory.

Quote:

There's a new surprise waiting, then

Quote:

As has been mentioned, it's not a default, but it was an idea tossed around some time ago by the developers.

The problem is that there is no real user specific storage available. It could of course simply go to the prefs or envarc directories, but those have specific semantics attached to them. Especially with data like bookmarks, logins, cookies and the like, an isolation is desirable.


As Elwood suggested, do not use it explicitly now, but go for the GetEnv/SetEnv calls. Right now, it's Timberwolf specific.

The new version of Timberwolf is currently in the os4depot upload queue and should pop up very soon.

This version fixes a few issues in addition to the issues fixed by beta 2. Here's a list of things changed:

* Tab headers are now rendered correctly
* Keyboard shortcuts work
* Menus now show tickmarks and submenu indicators
* Windows no longer open as a small stamp-sized thing in the corner but start out with their full size
* Toplevel window position and size are now handled correctly, even across sessions

Report any bugs you find to the Timberwolf bugtracker on os4depot.net

The tab header fix also includes a slight speedup for some webpages.

I'll be looking into the CPU load problem next. I noticed, though, that the CPU load drops substantially at one point after start (going as low as 3 %). I don't know how to reproduce this, but I saw it several times. If anybody finds a firm way to cause this behavior, please let me know.

Have fun, and thanks for the support. Much appreciated!

Edit: It's already out of the upload queue. Thanks orgin!

@ hotrod

Thanks, that is quite useful. I have one Amiga here that also exhibits the problem with not being able to store bookmarks, so chances are good that I can fix that problem soon.

Clipboard support is in the making.

@ kas1e

It seems, according to the email you sent me, that the main problem is the space in the filename. I'll definitely have to fix that. It should not crash.

In the end, it will most likely not work reliably from RAM disk since the file system doesn't support everything necessary for sqlite3, but then, storing bookmarks in a ram disk will not be of much use, anyway...

The problem with file systems can be "fixed" by assigning the CURRENTUSER: to another partition with appropriate file system.

@ mr2

I can't think of any reason why fontconfig should be a responsible for the bookmarks problem. However, I remember that on the Amiga I have here that does not store bookmarks, the fontcache was also out of sync.

Hmm.... The storing of bookmarks depends on a sane database structure, and this structure is created at first startup. It might be that the reconstruction of the out-of-sync data somehow interferes with that.

Thanks, mr2, that was a good observation

@ xenic

RANDOM: has to be mounted, I would suggest to move it to the DOSdrivers.

RANDOM is used for the entropy generation, and the absence has wide-reaching consequences. Shouldn't affect link colors, though.

@ ChrisH

Please make a bug report on our bugtracker, I'll see that I get it to work again

@ noelfuller

Page setup is for printing, and that's not in yet, same applies clipboard.

By the way, something you might also want to check out:

Under the tools menu, there should be an entry "open error console" or similar. If you get problems, like not being able to store bookmarks or saving stuff, check this console for possible warnings and/or errors.

@ nexus

Yeah, basically, if you wipe your old directory, then it should work. I don't understand really why it doesn't work for so many people. I use TW on an FFS partition, and bookmarks work without problem, although I'm mostly using the debug enabled build.

@ chris

regrading fontconfig: If we ever find the time, we'll probably write our own font backend for Cairo. That way, we can get rid of fontconfig.

@ all

Thanks for the detailed report and the new donations. Very welcome. Timberwolf is a massive project, so any support is greatly appreciated.

Quote:

Actually, they are both wrong, it's -s -f (for system and force). I try to get the damn letters right in the next version of the readme

Quote:

I doubt it's necessary. There has been some modification recently, but ram-handler is not a file system per se, it probably can't support it fully.


Thanks for all the bug reports, they are all quite detailed.


edit: Fixed quoted block

@ samo79

Did you select a disk with a space in the disk name ? Or anything with a space in it ?

In any case, please report it to the bug tracker, if possible with steps to reproduce the problem.

@ kas1e

Don't run it from ram disk. You need massive amount of memory to run it from there, and I'm not sure that RAM-handler supports the necessary file system features (In fact, I'm quite sure it doesn't)

The problem with the mutex are most likely due to the mutex being used before being initialized. I'll see that I can make that code more robust in pthreads.library. Since you're beta tester for OS4, can you please raise a bug report in the OS4 bugzila ? Thanks

Update: Please report bugs here

For those interested to continue testing Timberwolf, a new beta is available now (still in the OS4 depot upload queue for now).

Visit the project page for more information (there's a new update outlining the changes).

*cough cough cough* donate button *cough cough*


edit: Clarified thread title for front page display

@ portarinos

Just from the software error requester, it is impossible to say anything at all, especially if all the text is in Greek.

Can you provide me with the crash log, i.e. the one you can save with Grim Reaper ? Please send it to my email address thomas at friedenhq.org

Thanks.

@ vulture

The low memory figure is easily explained: TW needs about 200 MB to run. That means it will barely fit into a 1200 with 256MB and not at all in 128MB machines. That's most likely the cause for the slow startup too, it's likely swapping like crazy.

@ xenic

Yeah, I can now verify that, even without any activity on the web page, there's nearly 100 % of activity. I'll need to check that.

The 2MB of stack per thread is right now a "better safe than sorry". Since we can not easily implement stacks that enlarge themselves, we're a bit stuck with a high safety margin.

You are right, there's plenty of stuff that can be done. That's why it's labelled a beta version. As has been said several times, speed is not what we aimed at in this version.

@ agafaster

Rotating the ball would take too much graphics... it was meant as a joke