NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/atari/st/tech/6302

Internet Message Format | 1992-12-16 | 5.0 KB

Path: sparky!uunet!mcsun!uknet!gdt!aber!hrs
From: [e-mail] (Herbert Martin Sauro)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Sending objc_draw to a memory buffer rather than screen
Message-ID: <[e-mail]>
Date: 11 Dec 92 12:44:41 GMT
References: <[e-mail]> <[e-mail]>
Organization: University of Wales, Aberystwyth
Lines: 84

In article <[e-mail]> [e-mail] (David J Stevenson) writes:
>In <[e-mail]> [e-mail] (Adam Pelled) writes:
>
>
>>In article <[e-mail]>, [e-mail] (Herbert Martin Sauro) writes:
>>>I'm trying to write a scrollable list box. I've gone through a number of
>>>attempts. The best one so far was blitting n-1 of the entries in the list
>>>and writing the nth item using objc_draw as the list is scrolled.
>>>The trouble with this was if
>>>the user scrolled more than one item at a time this method no longer worked
>>>and instead the whole list box had to be redrawn (i.e using objc_draw)
>>>at the new position - which makes for flickering and it's slow.
>>>If the list box only moves one item at a time
>>>the n-1 blit method works a treat and without any flicker -- the list
>>>can also scroll pretty fast.
>
>>    Can't you vsync ? And what's wrong with a window ?
>I don't think that he meant the sort of flicker you can get when updating the
>screen as it's being displayed.  I suspect the apparent flicker is caused
>by clearing the redraw rect before drawing the text.

The sort of flicker I mean't is as follows. If you have the CPX
that controls the device drivers for the new FontGDOS then do the
following. Scroll through the device numbers using the up and down
arrow boxes and you will find that the
objects flicker around the edges. Personally I think this is poor
presentation (poor programming?) - I mean MS-windows doesn't flicker
like that so why should GEM.

>
>>>I'm now thinking of another method, this time to hold the entire list
>>>(or at least the section that is being displayed) in a memory buffer
>>>and as the list is scrolled just blit the appropriate section out to
>>>the screen. The trouble I'm having is how do I get such a list into
>>>a memory buffer in the first place. It's a shame that one can't redirect
>>>the output from the objc_draw command to a memory buffer rather than
>>>the screen (or can one?). So the question is, how can one store dialogs,
>>>sections of object trees etc in memory (as bit maps I mean) so that they
>>>can be blitted out to the screen at will?
>
>>    Yes you can redirect objc_draw() output by changing the screen physical
>>address. Of course it won't speed anything up, in fact it'll be slower plus
>>you'll soak up RAM. Xcontrl list boxes scroll o.k with a decent accelerator.
>NO, you should not change screen addresses, or you'll blow up with MultiTOS, or
>with some graphics boards or with n other things.
>
>To scroll the window, the method I would recommend is to blit the area that's
>common to the 'before' and 'after' displays, then call your redraw routine
>on the remaining rectangle at the top or bottom of the window.  Blitting,
>(vro_cpyfm) should normally be faster than drawing text, so only redraw the
>whole window when no part is common to the 'before' and 'after' displays,
>eg when the scroller has been 'paged'.
>
>Actually, I didn't quite understand why you were drawing the text with
>objc_draw; is each line in the list box a separate AES object?  The approach
>I use with listboxes is to make the whole of the scrollable area one object
>(a G_BOX), then use VDI functions to draw the text.  By mentioning 'blitting'
>and objc_draw, you imply that you are mixing AES and VDI calls to draw the
>scrollable area.
>--
>+---------------------------------------------------+
>| David Stevenson  [e-mail]   Tel: [phone] |
>+---------------------------------------------------+

What you describe is essentially what I'm doing, I'm only blitting the things
that are still in the list box before and after I scroll. After that I use
objc_draw to fill in the entries that are actually new to the list box.
Suggesting to use VDI to write out the text seems to be a good idea and
I'll give it a try. I was using a combination of vro_cpyfrm (spelling?)
and objc_draw and yes indeed I have a separate object for each entry which
might not be such a good idea now that you've mentioned it.

By the way David, if I remember wern't you asking me a while ago
about a monitor I was supposed to be getting for a TT (and the memory card!)
well I'm STILL waiting - moral of the story is DON'T DEAL WITH HCS!!!!
(For those not in the know - HCS is an Atari etc distributer in London, U.K.)


Herb
--
/******************************************************************************
Herbert Sauro                                   e-mail: [e-mail]
Biological Sciences                              phone: [phone]
Univesity College of Wales