primitiveDisplayCharacters

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

primitiveDisplayCharacters

Eliot Miranda-2
 
Hi All,

    I notice that primitiveDisplayCharacters calls copyBits for each character when doing blits that don't use copyLoopPixMap (as recorded in the quickBlt variable).  That means for certain usages we're invoking lockSurfaces & unlockSurfaces for each character.  It would be straight-forward to hoist the (un)lockSurfaces sends out of the loop.  Is there any reason not too do this?  i..e is there any reason why one would want (un)lockSurfaces invoked on each character in the quickBlt == false case?

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: primitiveDisplayCharacters

Bert Freudenberg
 
On Tue, Oct 16, 2018 at 4:59 PM Eliot Miranda <[hidden email]> wrote:
 
Hi All,

    I notice that primitiveDisplayCharacters calls copyBits for each character when doing blits that don't use copyLoopPixMap (as recorded in the quickBlt variable).  That means for certain usages we're invoking lockSurfaces & unlockSurfaces for each character.  It would be straight-forward to hoist the (un)lockSurfaces sends out of the loop.  Is there any reason not too do this?  i..e is there any reason why one would want (un)lockSurfaces invoked on each character in the quickBlt == false case?

You would have to know the affected area in advance to lock all at once. It that's easy to compute, sure.

Also, I'm not sure we're even using that primitive with the current fonts?

- Bert -
Reply | Threaded
Open this post in threaded view
|

Re: primitiveDisplayCharacters

Eliot Miranda-2
 
Hi Bert,
On Tue, Oct 16, 2018 at 5:50 PM Bert Freudenberg <[hidden email]> wrote:
 
On Tue, Oct 16, 2018 at 4:59 PM Eliot Miranda <[hidden email]> wrote:
 
Hi All,

    I notice that primitiveDisplayCharacters calls copyBits for each character when doing blits that don't use copyLoopPixMap (as recorded in the quickBlt variable).  That means for certain usages we're invoking lockSurfaces & unlockSurfaces for each character.  It would be straight-forward to hoist the (un)lockSurfaces sends out of the loop.  Is there any reason not too do this?  i..e is there any reason why one would want (un)lockSurfaces invoked on each character in the quickBlt == false case?

You would have to know the affected area in advance to lock all at once. It that's easy to compute, sure.

We can know a conservative estimate, knowing left, top & bottom, and right being less than or equal to the destination width.  If scanning right-to-left we can know right, top & bottom and that the right is >= 0 (with the complication of having to compute the width of the first character).   looking at the code it appears that this is fine; lockSurfaces supplies different values from unlockSurfaces (based on dx, dy, sx, sy, bbW & bbH).  unlockSurfaces uses affected[TBRL].

Also, I'm not sure we're even using that primitive with the current fonts?

Good point.  I should check.
 
- Bert -
 
_,,,^..^,,,_
best, Eliot