--- In
m("yahoogroups.com","ts-7000");">.com, Scott Zimmerman <> wrote:
>
> Can I ask what you do for graphics? Are you using X under the stock etch
> release that ships on the SD card?
>
Hi Scott,
My feelings are similar to Gary's. I'd like more documentation on the board specific aspects of the product - I shouldn't need to scan a script buried on the ftp site to find the watchdog address on a 7390 - but whenever I've contacted TS directly they've been very helpful in getting whatever information I've needed.
With regards graphics, on my application (industrial monitoring system running on the 7300 or 7390 platforms) I bypassed the off-the-shelf X and QT toolkits and write directly to the frame buffers using direct memory access and the available bitblt functions provided by the FPGA. I also wrote my own serial touch screen driver (7300) and touch screen handler (7390) for user input.
I quickly wrote as needed by the application optimized graphic functions for the various screen widgets and I feel I have a better control over the screen redraw process than via a 3rd party system. I now have functions to draw anti-aliased text in 10 different sizes/styles using different alignment and rotation from a single function call:
font_string(
Size,"Line 1|Line2|Line3",BaseAdr,Color,TextAlignement);
Throughout my code I use a VGAxy(x,y) macro to calculate screen memory locations and then add offsets for speed. I also have functions for boxes, frames, lines (with/without anti-aliasing), circles, curved boxes and frames, Icons, BitBlt, etc....
I use a dual screen approach where I draw to one screen page while displaying a second and then flipping between them. Finally, I use icons and other graphics on the spare pages of the screen memory (6MB) to store graphics I need quick access to which is simply a bitblt away. My application consists of complete screen redraws triggered by an event, but using the multiple buffers it would be easy to store a base screen (such as a dashboard without the gauge needles) and bitblt that screen into the new screen being displayed very quickly...
Using this approach the screen responsiveness is very good - by the time my finger has finished pressing the screen the new screen has been displayed, and I have no reason to need any speed increase for the UI.
The one downside to my approach is that my application is now 7300/7390 specific, but if necessary it could be ported to any device which gave direct access to the screen buffer.
Hope this was helpful,
PJE