Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The truth about VIDC, ViewFinder and VPod

227 views
Skip to first unread message

John Kortink

unread,
May 15, 2011, 7:19:39 AM5/15/11
to

It was high time to run some benchmarks on these, our only
three choices of Risc PC video hardware ...

Go here for the skinny :

http://web.inter.nl.net/users/J.Kortink/home/articles/graphbench/index.htm

Have fun ! (and think twice about that VPod ... ;-)).


John Kortink

--

Email : kor...@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink

? he od ot retteb gnihtoN

Dave Symes

unread,
May 15, 2011, 1:04:17 PM5/15/11
to
In article <6gdvs6hl045fuaaqp...@4ax.com>,
John Kortink <kor...@inter.nl.net> wrote:

> It was high time to run some benchmarks on these, our only
> three choices of Risc PC video hardware ...

> Go here for the skinny :

> http://web.inter.nl.net/users/J.Kortink/home/articles/graphbench/index.htm

> Have fun ! (and think twice about that VPod ... ;-)).

> John Kortink

The really interesting bit for me was the comment about 6.20 being slower
than 4.39.

I've been saying that for ages, but castigated by others who insist it's
faster.
So 6.20 is slower.

Dave

--

Dave Triffid

Rick Murray

unread,
May 15, 2011, 5:02:09 PM5/15/11
to
On 15/05/2011 19:04, Dave Symes wrote:

> The really interesting bit for me was the comment about 6.20 being slower
> than 4.39.

Surprised? Older RISC OS on older hardware can talk directly to the
VIDC. Newer RISC OS on newer hardware translates VIDC-style stuff into
whatever is expected by the newer hardware. This means there's an extra
layer of stuff happening in the graphics output which is, let's face it,
a pretty massive factor in a *graphical* user interface. :-)


Best wishes,

Rick.

Ron

unread,
May 15, 2011, 7:13:26 PM5/15/11
to
In message <6gdvs6hl045fuaaqp...@4ax.com>
John Kortink <kor...@inter.nl.net> wrote:

>
> It was high time to run some benchmarks on these, our only
> three choices of Risc PC video hardware ...
>
> Go here for the skinny :
>
> http://web.inter.nl.net/users/J.Kortink/home/articles/graphbench/index.htm
>
> Have fun ! (and think twice about that VPod ... ;-)).
>
>
> John Kortink
>

I have a Viewfinder with A7000/T in it. (SA RiscOS3.7)
Should I be looking out for a Radeon 9250? I have a spare Rage128 card,
is that of any use to me?

TIA Ron M.

Theo Markettos

unread,
May 15, 2011, 7:42:15 PM5/15/11
to
Dave Symes <da...@triffid.co.uk> wrote:
> The really interesting bit for me was the comment about 6.20 being slower
> than 4.39.

What I don't understand is the reason line plotting is 5-100x slower, but
over different OS/hardware combinations. For example the Rage128 is 100x
slower on RO6.2 than RO4.39, yet on VIDC there's only a 16% slowdown. But
the Radeon is 15x slower than Rage128 when they're both on RO4.39. And VPod
is 5x slower than VIDC on RO6.2. Small percentage differences I could
understand, but many large factors? Or is it measurement error?

Theo

John Kortink

unread,
May 16, 2011, 2:21:12 AM5/16/11
to
On 16 May 2011 00:42:15 +0100 (BST), Theo Markettos
<theom...@chiark.greenend.org.uk> wrote:

1) I'm not responsible for the 'Rage 128 only' ViewFinder driver
on RISC OS 6, RISC OS Ltd is (well, probably with ample looks
at a disassembly of my code ...). And, apparently, they didn't
bother to accelerate line drawing.

2) On Radeon line drawing is not accelerated either, because,
ATI 'fixed' the algorithm on Radeon (while it was tweakable
on Rage 128) which would cause a mismatch with line drawing
by the OS, which (because not all line drawing is accelerated)
can give rise to various inconsistencies. So I didn't bother.

3) Framebuffer access under ViewFinder and VPod is much slower
than under VIDC (something like 4 versus 40 MB/sec). So non-
accelerated plotting will always be faster on VIDC, although
by varying degrees depending on overheads.


John Kortink

--

Those who can, do. Those who can't, manage.

cfe...@freeremoveuk.com.invalid

unread,
May 16, 2011, 7:43:03 AM5/16/11
to
In message <6gdvs6hl045fuaaqp...@4ax.com>
John Kortink <kor...@inter.nl.net> wrote:

>
> It was high time to run some benchmarks on these, our only
> three choices of Risc PC video hardware ...
>
> Go here for the skinny :
>
> http://web.inter.nl.net/users/J.Kortink/home/articles/graphbench/index
> .htm
>
> Have fun ! (and think twice about that VPod ... ;-)).
>

Would the program run on the 'Beagleboard'?

If it did - the results could be interesting!

--
Colin Ferris Cornwall UK

Theo Markettos

unread,
May 16, 2011, 8:10:40 AM5/16/11
to
John Kortink <kor...@inter.nl.net> wrote:
> 1) I'm not responsible for the 'Rage 128 only' ViewFinder driver
> on RISC OS 6, RISC OS Ltd is (well, probably with ample looks
> at a disassembly of my code ...). And, apparently, they didn't
> bother to accelerate line drawing.

Thanks. Interesting to know the multiple interactions going on here.

And yes, BeagleBoard results would be very interesting. Though I don't know
how much acceleration there is, compared with the raw speed of the Beagle.

Theo

Tony Moore

unread,
May 16, 2011, 11:11:40 AM5/16/11
to
On 15 May 2011, Dave Symes <da...@triffid.co.uk> wrote:

[snip]

> The really interesting bit for me was the comment about 6.20 being
> slower than 4.39.

John's program GraphBench also shows that 4.39 runs considerably faster
on RPCemu (Vista, 1.8GHz), than on a RiscPC. Here, the difference is
between 2.6x (lines) and 29.8x (screen fill). Only Font plot is slower.

Tony

Matthew Phillips

unread,
May 16, 2011, 3:16:36 PM5/16/11
to
In message <8Oh*qu...@news.chiark.greenend.org.uk>

on 16 May 2011 Theo Markettos wrote:

> And yes, BeagleBoard results would be very interesting. Though I don't
> know how much acceleration there is, compared with the raw speed of the
> Beagle.

I've just uploaded results of running the benchmarking on our BeagleBoard xM
and our Iyonix, and I've posted some of the comparisons to the site also:

http://sinenomine.co.uk/graphbench/

Not surprisingly the BeagleBoard is rather faster than VIDC on RISC OS 4.39.
But against the ViewFinder Rage 128 on RO 4.39 it's slower for most of the
operations (apart from font plotting as you'd expect).

I don't think much advantage has been taken of the hardware acceleration yet!

The Iyonix scores very well on some of the rectangle and copying operations,
but in some cases is slower than a RISC PC with VIDC, which I find
surprising. I don't really understand these results: perhaps someone else
will be able to interpret them better.

I'm afraid quite a few of the screen modes were unavailable: I've not looked
to see if they would be possible if I had a fuller set of mode definitions or
a better monitor.

--
Matthew Phillips
Durham

John Kortink

unread,
May 16, 2011, 4:14:26 PM5/16/11
to

On Mon, 16 May 2011 20:16:36 +0100, Matthew Phillips
<mn...@sinenomine.freeserve.co.uk> wrote:

>[...]


>
>The Iyonix scores very well on some of the rectangle and copying operations,
>but in some cases is slower than a RISC PC with VIDC, which I find
>surprising. I don't really understand these results: perhaps someone else
>will be able to interpret them better.

Easily explained. Apparently only the plain rectangle fill
and copy are hardware accelerated on Iyonix (which is pretty
lazy software engineering ...), and framebuffer access is
roughly 20 MB/sec (on a Risc PC with VRAM its roughly 40),
which is pretty decent, considering there's a PCI bus in the
middle, but from a PCI point of view rather unspectacular.

>[...]


John Kortink

--

There's something to be said, for getting out of bed.

Alan Dawes

unread,
May 17, 2011, 6:32:39 AM5/17/11
to
In article <8Oh*qu...@news.chiark.greenend.org.uk>,

Here are my results comparing VPod RO620 with Beagleboard-xm running at
800MHz:
All values in activity per second (i.e. higher is better)

A is 'VPod RO620'
B is 'Beaglexm'

Mode : 800 x 600 x C256

-----------------------------------------------------------------
| Test / Benchmark | A | B |
-----------------------------------------------------------------
| Lines | 190 = 100% | 4622 = 2432% |
| Lines (EOR) | 187 = 100% | 4576 = 2447% |
| Circles | 482 = 100% | 1645 = 341% |
| Circles (EOR) | 430 = 100% | 139 = 32% |
| Screen fill | 1166 = 100% | 978 = 83% |
| Rectangle fill | 4352 = 100% | 3313 = 76% |
| Rectangle fill (EOR) | 2056 = 100% | 280 = 13% |
| Screen copy | 525 = 100% | 316 = 60% |
| Rectangle copy | 1987 = 100% | 1065 = 53% |
| Font plot | 507 = 100% | 3063 = 604% |
-----------------------------------------------------------------

Mode : 800 x 600 x C32K

-----------------------------------------------------------------
| Test / Benchmark | A | B |
-----------------------------------------------------------------
| Lines | 170 = 100% | 3856 = 2268% |
| Lines (EOR) | 170 = 100% | 3501 = 2059% |
| Circles | 434 = 100% | 982 = 226% |
| Circles (EOR) | 300 = 100% | 71 = 23% |
| Screen fill | 551 = 100% | 528 = 95% |
| Rectangle fill | 2098 = 100% | 1925 = 91% |
| Rectangle fill (EOR) | 988 = 100% | 143 = 14% |
| Screen copy | 244 = 100% | 171 = 70% |
| Rectangle copy | 939 = 100% | 622 = 66% |
| Font plot | 318 = 100% | 2119 = 666% |
-----------------------------------------------------------------

Mode : 800 x 600 x C16M

-----------------------------------------------------------------
| Test / Benchmark | A | B |
-----------------------------------------------------------------
| Lines | 151 = 100% | 4030 = 2668% |
| Lines (EOR) | 152 = 100% | 2347 = 1544% |
| Circles | 294 = 100% | 517 = 175% |
| Circles (EOR) | 165 = 100% | 32 = 19% |
| Screen fill | 237 = 100% | 275 = 116% |
| Rectangle fill | 913 = 100% | 1031 = 112% |
| Rectangle fill (EOR) | 433 = 100% | 66 = 15% |
| Screen copy | 106 = 100% | 83 = 78% |
| Rectangle copy | 412 = 100% | 324 = 78% |
| Font plot | 184 = 100% | 1290 = 701% |
-----------------------------------------------------------------

NB mode failed on BB for rest of test.

Alan

--
alan....@argonet.co.uk
alan....@riscos.org
Using an Acorn RiscPC

Rick Murray

unread,
May 17, 2011, 8:12:05 PM5/17/11
to
On 17/05/2011 12:32, Alan Dawes wrote:

Hmm...

> | Lines | 190 = 100% | 4622 = 2432% |

You look at that and you're like "Awesome!".


> | Rectangle fill (EOR) | 2056 = 100% | 280 = 13% |

Then you look at that and you're like "Oh... My... God!".


Best wishes,

Rick.

Alan Dawes

unread,
May 18, 2011, 5:21:36 AM5/18/11
to
In article <4dd30ed4$0$14680$ba4a...@reader.news.orange.fr>,

> Hmm...

My thoughts as well, but have a look at the comparison between VIDC RO439
and the Beagleboard-xm which suggests that when compared to the other
figures that VPOD is much slower at line drawing. (compare VIDC at 1324 /s
to VPOD at 190 /s and beagle at 4622 /s)

All values in activity per second (i.e. higher is better)

A is 'VIDC RO439'
B is 'Beaglexm'

Mode : 800 x 600 x C256

-----------------------------------------------------------------
| Test / Benchmark | A | B |
-----------------------------------------------------------------

| Lines | 1324 = 100% | 4622 = 349% |
| Lines (EOR) | 1319 = 100% | 4576 = 346% |
| Circles | 127 = 100% | 1645 = 1295% |
| Circles (EOR) | 91 = 100% | 139 = 152% |
| Screen fill | 68 = 100% | 978 = 1438% |
| Rectangle fill | 251 = 100% | 3313 = 1319% |
| Rectangle fill (EOR) | 187 = 100% | 280 = 149% |
| Screen copy | 50 = 100% | 316 = 632% |
| Rectangle copy | 184 = 100% | 1065 = 578% |
| Font plot | 1350 = 100% | 3063 = 226% |
-----------------------------------------------------------------

Mode : 800 x 600 x C32K

-----------------------------------------------------------------
| Test / Benchmark | A | B |
-----------------------------------------------------------------

| Lines | 1233 = 100% | 3856 = 312% |
| Lines (EOR) | 1240 = 100% | 3501 = 282% |
| Circles | 67 = 100% | 982 = 1465% |
| Circles (EOR) | 49 = 100% | 71 = 144% |
| Screen fill | 35 = 100% | 528 = 1508% |
| Rectangle fill | 136 = 100% | 1925 = 1415% |
| Rectangle fill (EOR) | 96 = 100% | 143 = 148% |
| Screen copy | 25 = 100% | 171 = 684% |
| Rectangle copy | 94 = 100% | 622 = 661% |
| Font plot | 1111 = 100% | 2119 = 190% |
-----------------------------------------------------------------

Mode : 800 x 600 x C16M

-----------------------------------------------------------------
| Test / Benchmark | A | B |
-----------------------------------------------------------------

| Lines | 1116 = 100% | 4030 = 361% |
| Lines (EOR) | 1120 = 100% | 2347 = 209% |
| Circles | 34 = 100% | 517 = 1520% |
| Circles (EOR) | 22 = 100% | 32 = 145% |
| Screen fill | 18 = 100% | 275 = 1527% |
| Rectangle fill | 69 = 100% | 1031 = 1494% |
| Rectangle fill (EOR) | 46 = 100% | 66 = 143% |
| Screen copy | 12 = 100% | 83 = 691% |
| Rectangle copy | 48 = 100% | 324 = 675% |
| Font plot | 800 = 100% | 1290 = 161% |
-----------------------------------------------------------------

druck

unread,
May 19, 2011, 3:38:25 PM5/19/11
to
On 16/05/2011 20:16, Matthew Phillips wrote:
> I'm afraid quite a few of the screen modes were unavailable: I've not looked
> to see if they would be possible if I had a fuller set of mode definitions or
> a better monitor.

Why can't your Iyonix do 1600x1200? It can do up to 2048x1536x32MB. I
assume it's because you only have a 1280x1024 monitor or something. In
which case you can load a MDF with higher res modes in it, when running
you wont see anything on the screen, but the results will still be produced.

---druck

Ste (news)

unread,
May 19, 2011, 6:57:38 PM5/19/11
to
In article <rr03t6d8bg4pe2fbo...@4ax.com>,

John Kortink <kor...@inter.nl.net> wrote:
> Easily explained. Apparently only the plain rectangle fill and copy are
> hardware accelerated on Iyonix (which is pretty lazy software engineering
> ...)

I think you'll find it's more likely to be constraints on the amount of time
people were able to put into the development of this stuff due to
timescales/shoestring budgets - IIRC the hardware acceleration on the Iyo
(such as it is) was pretty much a black project rather than sanctioned
development of fundamental OS features.

As we can see from the Beagle Board port, hardware acceleration is never
super high on the list of fundamentals which need to be implemented before a
system becomes usable; it's a nice-to-have.

Ta,

Steve

--
Steve Revill @ Home
Note: All opinions expressed herein are my own.

News poster

unread,
May 20, 2011, 3:41:24 AM5/20/11
to
In message <51d3dc5...@triffid.co.uk>
Dave Symes <da...@triffid.co.uk> wrote:

[snip]
>

> The really interesting bit for me was the comment about 6.20 being slower
> than 4.39.
>
> I've been saying that for ages, but castigated by others who insist it's
> faster.
> So 6.20 is slower.

It might be interesting to do the benchmarks with RO4 and Select as
well. There was much said of the performance increases in pre-4.39
versions of Select over RO4. Not that I ever noticed any.

Stan
--
An Iyonix in Buskerud.

http://mistymornings.net

Alan Dawes

unread,
May 20, 2011, 5:28:00 AM5/20/11
to
In article <ir3rje$h29$1...@dont-email.me>,

> ---druck

Reading his full post and having tried John's program on a beagleboard-xm
I had assumed that Matthew was referring to the Beagleboard not his Iyonix.

John Kortink

unread,
May 20, 2011, 5:28:05 AM5/20/11
to

On Thu, 19 May 2011 23:57:38 +0100, "Ste (news)"
<st...@revi11.plus.com> wrote:

>In article <rr03t6d8bg4pe2fbo...@4ax.com>,
> John Kortink <kor...@inter.nl.net> wrote:
>> Easily explained. Apparently only the plain rectangle fill and copy are
>> hardware accelerated on Iyonix (which is pretty lazy software engineering
>> ...)
>
>I think you'll find it's more likely to be constraints on the amount of time
>people were able to put into the development of this stuff due to
>timescales/shoestring budgets - IIRC the hardware acceleration on the Iyo
>(such as it is) was pretty much a black project rather than sanctioned
>development of fundamental OS features.

Getting to the point where hardware acceleration can be
exploited is vastly more work than accelerating a few
more graphics operations. Especially read-modify-write
rectangular operations should have been very little work
after doing the plain ones.

Whatever the reasons for not doing the development, the
result as seen by the end user is the same.


John Kortink

--

? he od ot retteb gnihtoN

cfe...@freeremoveuk.com.invalid

unread,
May 20, 2011, 6:07:25 AM5/20/11
to
In message <hgcct6d1bl43gn4ts...@4ax.com>
John Kortink <kor...@inter.nl.net> wrote:

>
> On Thu, 19 May 2011 23:57:38 +0100, "Ste (news)"
> <st...@revi11.plus.com> wrote:
>
> >In article <rr03t6d8bg4pe2fbo...@4ax.com>,
> > John Kortink <kor...@inter.nl.net> wrote:
> >> Easily explained. Apparently only the plain rectangle fill and
> >> copy are hardware accelerated on Iyonix (which is pretty lazy
> >> software engineering ...)

[snip]


>
> Getting to the point where hardware acceleration can be
> exploited is vastly more work than accelerating a few
> more graphics operations. Especially read-modify-write
> rectangular operations should have been very little work
> after doing the plain ones.
>
> Whatever the reasons for not doing the development, the
> result as seen by the end user is the same.
>

It seems many Moons ago - that someone wanted RO5 on the RPC.

Since it now seems available - what about a 32Bit version of Viewfinder
:-)

But it certainly be interesting - if the RO5 sources are understandable
- to add the extra 'hardware acceleration' for the Beagleboard/Iyonix.

Might even qualify for a 'Bounty Bar' :-)

JK thanks for your work - over the years - for 'Viewfinder' etc.

druck

unread,
May 20, 2011, 2:05:39 PM5/20/11
to
On 20/05/2011 10:28, Alan Dawes wrote:
> In article<ir3rje$h29$1...@dont-email.me>,
> druck<ne...@druck.org.uk> wrote:

>> Why can't your Iyonix do 1600x1200?
>

> Reading his full post and having tried John's program on a beagleboard-xm
> I had assumed that Matthew was referring to the Beagleboard not his Iyonix.

Other tables have results for modes which only one of the machines can
produce. Not much practical use, but it strange that the Iyonix was only
tested up to a pitifully small resolution (compared to what I use).

---druck

Matthew Phillips

unread,
May 20, 2011, 5:26:42 PM5/20/11
to
In message <ir6ahg$jct$1...@dont-email.me>

I was primarily providing the results for the Beaglboard, as fewer people own
one, but I thought I might as well do the Iyonix while I was at it.

We used to have a 19" CRT monitor which thankfully we got rid of at
Wakefield. The new 19" LCD doesn't go higher than 1280 x 1024 and I wasn't
interested enough to spend time mucking about with other MDFs.

We look forward to seeing your test results!

--
Matthew Phillips
Durham

Gerph

unread,
Jun 5, 2011, 8:25:58 AM6/5/11
to
On May 15, 12:19 pm, John Kortink <kort...@inter.nl.net> wrote:
> It was high time to run some benchmarks on these, our only
> three choices of Risc PC video hardware ...
>
> Go here for the skinny :
>
> http://web.inter.nl.net/users/J.Kortink/home/articles/graphbench/inde...

Whilst your results are vaguely interesting, I think there's a focus
on 'lines' which is inappropriate. It's been said in some of the posts
that lines are slow... this depends on what you're talking about and
what your test does. I've not looked at your benchmark code so cannot
comment but I think it's safe to infer from the benchmark results that
your 'lines' test is selecting random points on the screen and drawing
lines between them.

This is neither indicative of general use, nor a useful measure of the
general acceleration. Arbitrary lines are seldom used in the desktop,
and rarely outside it. The reason that it's not a good measure of
general acceleration, as people who've looked at the acceleration
interfaces will also know, is that arbitrary line drawing is
accelerated differently to horizontal and vertical line drawing.

Thus there should be (at least) 3 different measures of line drawing -
arbitrary, horizontal (hline) and vertical. If you're intent on
testing the speed of acceleration you should also test the poly-hline
interface as well, in comparison to multiple hline calls. Horizontal
line is a fundamental of many rendering operations and is used where
no dedicated acceleration is applicable.

For example, a rectangle can be drawn by either an accelerated
rectangle call, or multiple calls to hline. (it could also be drawn by
a single or multiple calls to poly-hline, but I can't say whether that
was implemented - it wasn't when I stopped doing things). The hline
call itself can be implemented either accelerated or as direct memory
access.

So for a rectangle fill you might get (at least) 3 different figures
from the same hardware with different acceleration levels. Usually a
graphics driver would provide hline as the very first accelerated
operation because so much depends on it. Next the driver would
probably implement rectangle fill. Then rectangle copy. Arbitrary line
drawing is down there with accelerated ellipse drawing - a late thing
to implement because it's not important to most use (ok maybe not that
far down - ellipse drawing is pretty much irrelevant!).

Additionally, the type of colour used by the graphics operations (for
both line and rectangle) is important. Different code paths might be
used for solid compared to patterned colours - patterned colours such
as might be generated by setting the 'dither' flag on the ColourTrans
colour selection calls. And the operations can be changed again by
using operations that aren't just solid fills - for example a EOR
plot. Or, more esoterically a EOR pixel, solid pixel, OR pixel, AND
pixel operation (or if you were in a 32 bit mode, an operation that
masked or set just one component of the colours) - you could have so
much fun with the pattern operations if you were so inclined. These
latter operations aren't used often (CC did some fun things -
DitherExtend is a very interesting module, IIRC).

Anyhow, of those types of operations, the basic dither and EOR
operations are the most likely to be used and can be tested
independently.

I'm not certain how dashed line drawing is performed, but I believe
it's implemented as direct access without acceleration. I'd be happy
to be wrong there though. Dashed lines are important in the desktop
because the drag boxes use them - but less important than most other
operations.

So, if you're going to do any useful comparison of the operations you
should consider the 3 line operations independently - arbitrary line
drawing is not a good measure of the general use. And to be a bit more
thorough, try the operations with different

As for graphics operations in general being slower... yes, that's a
side-effect of vectoring the calls to give them an abstraction. Could
that be faster, probably. I look at some of the timings now and I'm as
perplexed as I was back then that the slowdown was as high as it was
for certain things. But time pressures and other things often cause
you to accept what works over what's perfect. In any case it's about 6
years since I did anything with this stuff so you can expect both hazy
recollection - and of course huge amounts should have happened since
those first tentative steps were being made.

Amusingly, a few days ago (before I saw this thread) I stumbled upon
an old '~Done/Benchmarker' directory, which had - in addition to the
test code - two logs which were used as comparisons to one another,
not just for the graphics system.

You can find them at:

http://usenet.gerph.org/Benchmarker/

--
Gerph

John Kortink

unread,
Jun 5, 2011, 11:10:23 AM6/5/11
to

On Sun, 5 Jun 2011 05:25:58 -0700 (PDT), Gerph <ge...@gerph.org>
wrote:

>On May 15, 12:19 pm, John Kortink <kort...@inter.nl.net> wrote:
>> It was high time to run some benchmarks on these, our only
>> three choices of Risc PC video hardware ...
>>
>> Go here for the skinny :
>>
>> http://web.inter.nl.net/users/J.Kortink/home/articles/graphbench/inde...
>
>Whilst your results are vaguely interesting, I think there's a focus
>on 'lines' which is inappropriate.

There's no 'focus' on lines in my benchmarks at all.

It's just a representative of one of the three major types
of operations that all others are derived from : lines, odd
solid shapes (built from horizontal lines), and rectangles.

>It's been said in some of the posts
>that lines are slow... this depends on what you're talking about and
>what your test does. I've not looked at your benchmark code so cannot
>comment but I think it's safe to infer from the benchmark results that
>your 'lines' test is selecting random points on the screen and drawing
>lines between them.
>
>This is neither indicative of general use, nor a useful measure of the
>general acceleration.

On the contrary. That is exactly what it is.

What the desktop uses (basically only the odd horizontal and
vertical line to draw e.g. window borders) is specific. Not
the other way around.

In any way, those are drawn even quicker than arbitrary ones
(at least under ViewFinder), since they're just degenerate
cases of rectangle fill.

>Arbitrary lines are seldom used in the desktop,

Even worse. Lines in general are seldom used in the desktop
(which is exactly what I point out on my web page ...).

>and rarely outside it. The reason that it's not a good measure of
>general acceleration, as people who've looked at the acceleration
>interfaces will also know, is that arbitrary line drawing is
>accelerated differently to horizontal and vertical line drawing.
>Thus there should be (at least) 3 different measures of line drawing -
>arbitrary, horizontal (hline) and vertical.

No, there shouldn't. Horizontal and vertical lines are covered
by rectangle fill. See above.

>If you're intent on
>testing the speed of acceleration you should also test the poly-hline
>interface as well, in comparison to multiple hline calls. Horizontal
>line is a fundamental of many rendering operations and is used where
>no dedicated acceleration is applicable.

Multiple horizontal lines is covered by circle fill. And, as
usual, very much faster on ViewFinder (which caches the lines
of shapes before drawing them).

>For example, a rectangle can be drawn by either an accelerated
>rectangle call, or multiple calls to hline. (it could also be drawn by
>a single or multiple calls to poly-hline, but I can't say whether that
>was implemented - it wasn't when I stopped doing things). The hline
>call itself can be implemented either accelerated or as direct memory
>access.

As you say : implementation details. It doesn't add to the set
of important benchmarks.

>So for a rectangle fill you might get (at least) 3 different figures
>from the same hardware with different acceleration levels.

Only the fastest one is interesting. Why would slower ways
of drawing be interesting to benchmark ?

>[...]


>
>Additionally, the type of colour used by the graphics operations (for
>both line and rectangle) is important. Different code paths might be
>used for solid compared to patterned colours - patterned colours such
>as might be generated by setting the 'dither' flag on the ColourTrans
>colour selection calls. And the operations can be changed again by
>using operations that aren't just solid fills - for example a EOR
>plot. Or, more esoterically a EOR pixel, solid pixel, OR pixel, AND
>pixel operation (or if you were in a 32 bit mode, an operation that
>masked or set just one component of the colours) - you could have so
>much fun with the pattern operations if you were so inclined. These
>latter operations aren't used often (CC did some fun things -
>DitherExtend is a very interesting module, IIRC).

Patterned operations are rarely used in the desktop. Even
so, ViewFinder accelerates most of them as well (by huge
numbers I might add. I suppose I was bored ...).

It's interesting to note that under RISC OS, since it does
everything in software, solid operations are basically
degenerate cases of patterned ones. They're not that special,
really. Not even to an accelerated drawing engine ...

>Anyhow, of those types of operations, the basic dither and EOR
>operations are the most likely to be used and can be tested
>independently.
>
>I'm not certain how dashed line drawing is performed, but I believe
>it's implemented as direct access without acceleration. I'd be happy
>to be wrong there though. Dashed lines are important in the desktop
>because the drag boxes use them - but less important than most other
>operations.

Almost negligible, in fact.

>So, if you're going to do any useful comparison of the operations you
>should consider the 3 line operations independently - arbitrary line
>drawing is not a good measure of the general use. And to be a bit more
>thorough, try the operations with different

Feel free, if you think it creates interesting benchmarks.

But as I've told you above, it doesn't. Apparently you need
to learn where to look.

>[...]


John Kortink

--

Those who can, do. Those who can't, manage.

cfe...@freeremoveuk.com.invalid

unread,
Jun 6, 2011, 8:37:38 AM6/6/11
to
In message <163nu65o4lipn8kus...@4ax.com>
John Kortink <kor...@inter.nl.net> wrote:

>
> On Sun, 5 Jun 2011 05:25:58 -0700 (PDT), Gerph <ge...@gerph.org>
> wrote:
>
> >On May 15, 12:19 pm, John Kortink <kort...@inter.nl.net> wrote:
> >> It was high time to run some benchmarks on these, our only
> >> three choices of Risc PC video hardware ...

[snip]

Breaking into your fun :-|

Does/did 'Viewfinder' work with Acorn 'DDT' debugger?

Thanks

John Kortink

unread,
Jun 6, 2011, 10:17:15 AM6/6/11
to

On Mon, 06 Jun 2011 13:37:38 +0100, cfe...@freeRemoveuk.com.invalid
wrote:

No idea. Never used it.

If it fails to work, it has to do something really obscure
and/or nasty, graphically speaking.


John Kortink

--

There's something to be said, for getting out of bed.

Theo Markettos

unread,
Jun 6, 2011, 4:02:24 PM6/6/11
to
John Kortink <kor...@inter.nl.net> wrote:
>
> On Mon, 06 Jun 2011 13:37:38 +0100, cfe...@freeRemoveuk.com.invalid
> wrote:
> >Does/did 'Viewfinder' work with Acorn 'DDT' debugger?
>
> No idea. Never used it.
>
> If it fails to work, it has to do something really obscure
> and/or nasty, graphically speaking.

I wouldn't be surprised. AFAIK it appears to be an Arthur or RISC OS 2
version of the Wimp, but with an added debugging environment. Graphically
RO2 did most of its stuff via the VDU calls (*Spool/*Print was already fun)
but I don't know if this was changed to avoid reentrancy issues in the
debugger. I wouldn't be surprised if it was fairly nasty underneath.

Theo

cfe...@freeremoveuk.com.invalid

unread,
Jun 7, 2011, 7:21:21 AM6/7/11
to
In message <03opu61tginlfkvhe...@4ax.com>
John Kortink <kor...@inter.nl.net> wrote:

>
> On Mon, 06 Jun 2011 13:37:38 +0100, cfe...@freeRemoveuk.com.invalid
> wrote:
>
> >In message <163nu65o4lipn8kus...@4ax.com>
> > John Kortink <kor...@inter.nl.net> wrote:
> >
> >>
> >> On Sun, 5 Jun 2011 05:25:58 -0700 (PDT), Gerph <ge...@gerph.org>
> >> wrote:
> >>
> >> >On May 15, 12:19 pm, John Kortink <kort...@inter.nl.net> wrote:
> >> >> It was high time to run some benchmarks on these, our only
> >> >> three choices of Risc PC video hardware ...
> >
> >[snip]
> >
> >Breaking into your fun :-|
> >
> >Does/did 'Viewfinder' work with Acorn 'DDT' debugger?
>
> No idea. Never used it.
>
> If it fails to work, it has to do something really obscure
> and/or nasty, graphically speaking.
>

Thanks for that info.

Seem to remember a flying prog 'Chocks Away' working with one of the
'Viewfinder' versions - can't remember which version - were some of the
'Viewfinder' versions different?

Anyone out there recommend a flying prog that works with 'Viewfinder' -
would prefer a 'Light Aircraft' version.

JK doesn't seems to have made much of - the redone/updated
Podule/Video-carrier-board.

Bye

cfe...@freeremoveuk.com.invalid

unread,
Jun 8, 2011, 5:26:08 PM6/8/11
to
In message <03opu61tginlfkvhe...@4ax.com>
John Kortink <kor...@inter.nl.net> wrote:

>
> On Mon, 06 Jun 2011 13:37:38 +0100, cfe...@freeRemoveuk.com.invalid
> wrote:
>
> >In message <163nu65o4lipn8kus...@4ax.com>
> > John Kortink <kor...@inter.nl.net> wrote:
> >
> >>
> >> On Sun, 5 Jun 2011 05:25:58 -0700 (PDT), Gerph <ge...@gerph.org>
> >> wrote:
> >>
> >> >On May 15, 12:19 pm, John Kortink <kort...@inter.nl.net> wrote:
> >> >> It was high time to run some benchmarks on these, our only
> >> >> three choices of Risc PC video hardware ...
> >
> >[snip]
> >
> >Breaking into your fun :-|
> >
> >Does/did 'Viewfinder' work with Acorn 'DDT' debugger?
>
> No idea. Never used it.
>
> If it fails to work, it has to do something really obscure
> and/or nasty, graphically speaking.
>

Taking note from Martin W and Druck - have tried a version of 1.44 (27
May 2002) Viewfinder with debugger DDT 1.87 (13 Sep 2002) and they seem
to work ok.

0 new messages