Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #918 > unrolled thread

FontV information

Back to article view | Back to comp.sys.acorn.programmer

Contents

  FontV information wpb <w.blatchley@yahoo.com> - 2011-10-24 06:05 -0700
    Re: FontV information Martin Wuerthner <spamtrap@mw-software.com> - 2011-10-24 19:14 +0200
      Re: FontV information wpb <w.blatchley@yahoo.com> - 2011-10-24 10:31 -0700
        Re: FontV information Martin Wuerthner <spamtrap@mw-software.com> - 2011-10-25 10:23 +0200
          Re: FontV information John Tytgat <this@is.invalid> - 2011-10-25 14:12 +0200
            Re: FontV information Martin Wuerthner <spamtrap@mw-software.com> - 2011-10-26 13:01 +0200
              Re: FontV information druck <news@druck.org.uk> - 2011-10-27 11:08 +0100
                Re: FontV information wpb <w.blatchley@yahoo.com> - 2011-10-31 00:53 -0700
                  Re: FontV information John Tytgat <this@is.invalid> - 2011-10-31 11:51 +0100
                  Re: FontV information Martin Wuerthner <spamtrap@mw-software.com> - 2011-10-31 12:01 +0100
                    Re: FontV information wpb <w.blatchley@yahoo.com> - 2011-11-07 07:53 -0800

#918 — FontV information

Hi there,

Can anyone point me to where FontV is decribed in documentation? I've
tried the PRMs and StrongHelp, but can't find anything. The ROOL wiki
also has nothing on this. Any pointers much appreciated.

Cheers,

WPB

[toc] | [next] | [standalone]

#919

In message <64f80047-9db1-48f1-8d06-7397d55ff68d@v8g2000vbe.googlegrou 
ps.com>
          wpb <w.blatchley@yahoo.com> wrote:

> Can anyone point me to where FontV is decribed in documentation? I've
> tried the PRMs and StrongHelp, but can't find anything. The ROOL wiki
> also has nothing on this. Any pointers much appreciated.

If there was such a thing as FontV in RISC OS it would presumably 
vector the Font SWIs, in the same way as SpriteV vectors the Sprite 
SWIs. There is a number reserved for FontV (0x25), but I am not aware 
of any RISC OS version that actually uses it to vector the Font SWIs.

The number must have been reserved back in the days of RISC OS 3.5 
development because RO3.5 already supports vector number 0x26 
(PointerV).

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#920

On Oct 24, 7:14 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> In message <64f80047-9db1-48f1-8d06-7397d55ff...@v8g2000vbe.googlegrou
> ps.com>
>           wpb <w.blatch...@yahoo.com> wrote:
>
> > Can anyone point me to where FontV is decribed in documentation? I've
> > tried the PRMs and StrongHelp, but can't find anything. The ROOL wiki
> > also has nothing on this. Any pointers much appreciated.
>
> If there was such a thing as FontV in RISC OS it would presumably
> vector the Font SWIs, in the same way as SpriteV vectors the Sprite
> SWIs. There is a number reserved for FontV (0x25), but I am not aware
> of any RISC OS version that actually uses it to vector the Font SWIs.
Vectoring the Font Manager SWIs is what I was hoping for, yes. Looks
like that's not possible...

> The number must have been reserved back in the days of RISC OS 3.5
> development because RO3.5 already supports vector number 0x26
> (PointerV).
>
> --
> Martin
Thanks for the info!

[toc] | [prev] | [next] | [standalone]

#924

In message <e8df8230-2cb9-4857-94bc-b81c6b757f44@r2g2000vbj.googlegrou 
ps.com>
          wpb <w.blatchley@yahoo.com> wrote:

> On Oct 24, 7:14 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
>> In message <64f80047-9db1-48f1-8d06-7397d55ff...@v8g2000vbe.googlegrou
>> ps.com>
>>           wpb <w.blatch...@yahoo.com> wrote:
>>
>>> Can anyone point me to where FontV is decribed in documentation? I've
>>> tried the PRMs and StrongHelp, but can't find anything. The ROOL wiki
>>> also has nothing on this. Any pointers much appreciated.
>>
>> If there was such a thing as FontV in RISC OS it would presumably
>> vector the Font SWIs, in the same way as SpriteV vectors the Sprite
>> SWIs. There is a number reserved for FontV (0x25), but I am not aware
>> of any RISC OS version that actually uses it to vector the Font SWIs.
> Vectoring the Font Manager SWIs is what I was hoping for, yes. Looks
> like that's not possible...

Yes. It is unclear to me why Sprite and Draw calls are vectored, but 
Font calls are not. Makes the whole printer driver mechanism rather 
more complicated than necessary. The effort that was put into the 
FontSWI mechanism that printer drivers use to intercept Font calls 
(requiring the active co-operation of the FontManager, which is not 
good design) would have been better spent on implementing the FontV 
vector.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#926

On 10/25/2011 10:23 AM, Martin Wuerthner wrote:
> Yes. It is unclear to me why Sprite and Draw calls are vectored, but
> Font calls are not.

I always thought this was because of performance reasons (but no proof 
for that).  Although the extra indirection via FontV could be avoided by 
the FM when it detects it is the only one on the FontV chain list so 
maybe this is not so relevant.

> Makes the whole printer driver mechanism rather
> more complicated than necessary. The effort that was put into the
> FontSWI mechanism that printer drivers use to intercept Font calls
> (requiring the active co-operation of the FontManager, which is not
> good design) would have been better spent on implementing the FontV
> vector.

I'm not entirely convinced a FontV intercepting PDriver* would result in 
less complexity.  E.g. Font_Paint implementation would need to do all 
font graphics state bookkeeping itself (while now it is done by FM, 
mostly in parallel what the PDriver* is already doing in a very limited 
way).

But on the other hand, as it is, it's not such a nice design atm.

John.

[toc] | [prev] | [next] | [standalone]

#931

In message <j8693u$laa$1@dont-email.me>
          John Tytgat <this@is.invalid> wrote:

> On 10/25/2011 10:23 AM, Martin Wuerthner wrote:
>> Yes. It is unclear to me why Sprite and Draw calls are vectored, but
>> Font calls are not.

> I always thought this was because of performance reasons (but no proof
> for that).  [...]

I do not think that can have been the reason because there is no 
substantial difference between FontV and SpriteV in terms of the 
number of calls and the complexity of a single call. Both are 
relatively high-level and therefore ideal for vectoring. There are 
lots of SWIs that are called much more often and do less per call 
(which means the overhead of vectoring is more noticeable) and they 
are still vectored, e.g., WrchV. Looking at David Ruck's VecStat, the 
number of times WrchV, ByteV, MouseV, ChangeEnvV are called dwarves 
the number of SpriteV calls, and FontV would probably be similar.

Interestingly, in a typical desktop environment, it is RemV that is 
called most often (around 9 million times in the 10 minutes I spent 
writing this message), followed by MouseV, ByteV (5 million), 
ChangeEnvV (3 million), WrchV (1.2 million). The number of SpriteV 
calls is negligible at 33,000 and FontV would be in that region, too.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#940

On 26/10/2011 12:01, Martin Wuerthner wrote:
> I do not think that can have been the reason because there is no
> substantial difference between FontV and SpriteV in terms of the
> number of calls and the complexity of a single call. Both are
> relatively high-level and therefore ideal for vectoring. There are
> lots of SWIs that are called much more often and do less per call
> (which means the overhead of vectoring is more noticeable) and they
> are still vectored, e.g., WrchV. Looking at David Ruck's VecStat, the
> number of times WrchV, ByteV, MouseV, ChangeEnvV are called dwarves
> the number of SpriteV calls, and FontV would probably be similar.

I was surprised by the sheer number of calls per second when I wrote it, 
following on from SWIstat, APPstat and SERVstat which you can find at 
http://www.armclub.org.uk/free/

> Interestingly, in a typical desktop environment, it is RemV that is
> called most often (around 9 million times in the 10 minutes I spent
> writing this message), followed by MouseV, ByteV (5 million),
> ChangeEnvV (3 million), WrchV (1.2 million). The number of SpriteV
> calls is negligible at 33,000 and FontV would be in that region, too.

The overhead for vectorising calls is negligible compared to anything 
the call actually does, or even the SWI decode and dispatch mechanism 
itself.

---druck

[toc] | [prev] | [next] | [standalone]

#960

Would there be any use in adding support to RO5 for FontV at this
stage, or would the fact that RO4/6 don't support it make the addition
essentially useless? My own reasons for wanting to vectorise the calls
would be nullified by the OS split, unfortunately.

[toc] | [prev] | [next] | [standalone]

#964

On 10/31/2011 8:53 AM, wpb wrote:
> Would there be any use in adding support to RO5 for FontV at this
> stage, or would the fact that RO4/6 don't support it make the addition
> essentially useless? My own reasons for wanting to vectorise the calls
> would be nullified by the OS split, unfortunately.

Whether really using FontV is useful or not depends on its anticipated 
usecases which we wouldn't be able to implement today.  So what's yours ?

John.

[toc] | [prev] | [next] | [standalone]

#965

In message <8144d323-0340-4c01-96a2-bd40ea24d8ad@1g2000vbx.googlegroup 
s.com>
          wpb <w.blatchley@yahoo.com> wrote:

> Would there be any use in adding support to RO5 for FontV at this
> stage, or would the fact that RO4/6 don't support it make the addition
> essentially useless? My own reasons for wanting to vectorise the calls
> would be nullified by the OS split, unfortunately.

The question is: What do you actually want to do with FontV? Is this 
really required for what you have in mind?

Secondly, I cannot see why the OS split would make such a big 
difference. Even if the OS was not split, your software would only 
work on a new version of the OS with this feature present and would 
fail to work on 99.9% of RISC OS systems that do not have that very 
latest version installed.

Finally, if there is a good reason for FontV support I cannot see why 
it could not be implemented in both source trees. Of course, 
deployment to users would require a new end-user version, but that 
affects both branches.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1007

Well, I had two possible ideas in mind:

- Intercept Font_Paint calls to do glyph substitution when they might
not be available in the current font. But having thought about this
some more, it would require so much housekeeping, it would probably be
better done by modifying the FontManager sources directly.

- Intercept Font_Paint calls to make a slightly less hacky version of !
Swipe (http://astubbs.drobe.co.uk/swipe.html). This is really just for
fun, but also because I found !Swipe really useful back when I had an
OS it worked on. I'd forgotten about it until recently, and when I
came back to it, I thought it would be educational to try to
reimplement it a little more cleanly. (As I remember, it overwrote the
Font_Paint address in the SWI dispatch table within the module as a
way of hooking the code. Ugh!)

Anyway, looks like I'd have to use something like nemo's VectorExtend
(if it is ever released!), or a totally different approach...

Thanks for your thoughts, anyway.

Cheers,

WPB

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web