Cairo image surface doesn't use any intuition call at all. WebKit renders in the Cairo surface (generic), and OWB retrieve the resulting surface data in memory and blits it with BltBitmap() or WritePixelArray() depending on the blitting step.

@Fab
Then what reassons for speedup if only FillRect() are updated ? Did FillRect() involved in any inderect way ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Without doing any benchmarks or speed tests I can say that up4
on my 440ep has made not only speed improvements but also usability
improvements.

For example Timberwolf feels more close to beta than alpha. Still
takes time to load but is certainly more usable and 'feels'
different.

Some other things that felt....er...clunky...now just work smooth(?).

This is one great update. This little Sam440ep is a fun, usable,
stable system. Oh, did I mention fun.

(Wow, if X1000 were to run only twice as fast, add Altivec,,,,Zoommm!)

@kas1e

FillRect isn't used anywhere in OWB rendering/blitting stage, so it's either placebo, or something else was improved too.

@kas1e
Quote:

Then what reassons for speedup if only FillRect() are updated ? Did FillRect() involved in any inderect way ?

From the rtg.library release note:

- Removed WaitBiltter() calls from right after HW accelerated blitter calls. This increases the overall performance by allowing CPU and GPU to work simultaneously (e.g., gives 2.7 times speed increase in P96Speed BltBitMap() benchmark)

From Picasso96API.library release note:

- Removed unnecessary blitter wait calls for better performance (also inserted blitter wait calls elsewhere where they are actual needed)

Both modifications done by Hans de Ruiter

_________________
Massimiliano Tretene, ACube Systems, Soft3

@m3x
Thanks :)

Through, a bit sad that with new update we not have full detailed log (as it was for update3), and that leave us with questions .. Maybe you can somehow convince others in HP to bring full-change logs all the time with all the updates ?:)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@m3x

Ouch, almost x3... Must be really slow before. Anyway, that definitely explains a speedup in OWB, since BltBitmap is used to render the committed changes (here, it usually takes about 20-30ms to blit a full page, so assuming it was at least 3 times as slow, that would have made scrolling/rendering really slow).

If kprintf worked properly in OS4, you could even benchmark the speedup with setenv OWB_BENCHMARK 1.

@Fab

Doesn't kprintf work properly? I tend to use DebugPrintF() directly, but I figured at the very least kprintf would map to that...

_________________
Playstation Network ID: xeron6

@xeron
When you use kprintf directly from the clib2 programms then it works fine, but when you use kprintf direclty from newlib progs, its sometime works, but sometime just crashes. Back in past someone on utilitybase say that its "ok" to use clibs2's *.a which contain kprintf, but in reality that was no-go because of crashes.

And instead we just use redefine of kprintf to DebugPrintF(). Through do not remember if i add that to reliase version of os4 port of fab's owb, but if not, then for sure will do with next version.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Well the debug output was there already, but it reported "f ms" only, as far as timing goes.

Last edited by Thematic on 29-Dec-2011 at 02:40 PM.

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

Quote:

Well the debug output was there already, but it reported "f ms" only, as far as timing goes.

That suggests the original kprintf call uses %f but that is not supported in IExec-RawDoFmt, which underlies all system #?Printf#? calls.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

great update, hope everyone is happy and understand how much work it was to get this one out the door.

To all in the OS4 team , wonderfull job, keep up the good work.

_________________
See my blog and collection website! . https://www.blog.amigaguru.com

@broadblues

Probably would be better if kprintf did a vasnprintf() or so and passed the result to DebugPrintF...

_________________
Playstation Network ID: xeron6

@broadblues

Quote:

That suggests the original kprintf call uses %f but that is not supported in IExec-RawDoFmt, which underlies all system #?Printf#? calls.

with the exception of DebugPrintF() which uses printf()-style formatting.

@xeron
Quote:

Probably would be better if kprintf did a vasnprintf() or so and passed the result to DebugPrintF...

Or use a temporary buffer, since DebugPrintF() uses 68k varargs.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray