Grx February 2003

grx@gnu.de

6 participants
14 discussions

x11 font driver independence
by Dimitar Zhekov 26 Feb '03

26 Feb '03

This patch changes the x11 font driver to use it's own X11 display and window. It allows X11 fonts to be loaded before GrSetMode() and makes the font driver independent from the X11 video and frame drivers. Additionally, it is now certain that all X11 video/frame drivers variables are used by these drivers only (correct me if I'm wrong). So now I'll try to fix the X11 video output (it either has no buffering or it doesn't work at all), but wanted to get rid of the font driver accessing X11 video/frame first. Any comments? Note: incrementional patch - apply x11-fdv-ulpos-fix.diff first. -- E-gards: Jimmy

2 1

fontdemo load order fix [RFC]
by Dimitar Zhekov 25 Feb '03

25 Feb '03

The X11 font driver requires a GrSetMode() before GrLoadFont(). fontdemo does the opposite, because it uses the font height to determine GrSetMode() width and height. Thus, xfontdemo can't actually load X fonts. The not-seriously-tested quickfix attached fixes this, but please don't apply it yet except for testing purposes. I'll try to change the font driver instead. -- E-gards: Jimmy

1 0

test/makefile.x11 library dependency fix
by Dimitar Zhekov 25 Feb '03

25 Feb '03

Just a typo. The X11 tests depend on $(GRX20X) [== libgrx20X.a], not on $(GRX20) [undefined]. -- E-gards: Jimmy

1 0

X11 font driver underlining fix
by Dimitar Zhekov 25 Feb '03

25 Feb '03

The X11 font driver uses font descent as underline height, i.e. the entire space below the baseline goes to underlining. This is too much, for example "gadfly" in 8x16 baseline=12 looks like this: ................................................ ................................................ ......................#.....###...##............ ......................#....#.......#............ ......................#....#.......#............ ..#####...#####...#####..#####.....#.....#....#. .#....#..#....#..#....#....#.......#.....#....#. .#....#..#....#..#....#....#.......#.....#....#. .#....#..#....#..#....#....#.......#.....#....#. .#....#..#....#..#....#....#.......#.....#....#. .#....#..#...##..#....#....#.......#.....#....#. ..#####...###.#...#####....#......###.....#####. ################################################ ################################################ ################################################ ################################################ This patch syncs ulheight/ulpos calculation with all other drivers for which ulheight isn't known. Albeit not perfect, the result is quite decent. -- E-gards: Jimmy

1 0

Re: Patch for fd_win32.c
by Demmer, Thomas 20 Feb '03

20 Feb '03

See below (I hate Outlook...) > -----Original Message----- > From: Mariano Alvarez Fernandez [SMTP:malfer@telefonica.net] > Sent: Mittwoch, 19. Februar 2003 21:37 > To: Demmer, Thomas > Cc: grx(a)gnu.de > Subject: Re: Patch for fd_win32.c > > Demmer, Thomas wrote: > > Hi all, > > as promised, here are the patch files for MS Windows to > > use Device Independent Bimaps to speed up. > > Thanks a lot for your work Thomas. > > - About the "get rid of GRXMain" part: > > I will integrate it in the next pre-release. I have changed the vdriver > a bit, I think is much cleaner. I attach it for review. Good to hear. I'll check it. > - About the DIB aproach: > > Is very interesting and really fast!. But now than you have a pointer to > a "24 bpp linear frame buffer" (the bitmap), why not use the standard > GRX framebuffer with them? > > The idea is to clone the fdrivers/lfb24.c in fdrivers/lfb24w32.c (by > example) using a new driver name (like GR_frame24W32_LFB by example). I > suspect the only things to add are the apropiate InvalidateRects. > > Hmm, I have been stealing in ram24.c, apparently I have been searching in the wrong places. Looks to me like a major peace of surgery, but thanks for the pointer. At least I will have to change the DIB to being a top-down bitmap instead of being bottom-up. I do not have the slightest idea why MS made that the default. Ciao Tom

1 0

ASCII fonts may not contain undpos
by Dimitar Zhekov 19 Feb '03

19 Feb '03

After a quick investigation, I fugired out that not only isn't undpos in the .fna files 1-based, but it isn't even supported. So, as I wrote the (wrong) .fna related stuff, here is the fix. The patch also fixes fna's driver inability to read fonts with 2+ nonempty "note"-s and obsoletes ulpos-0-based.diff, which should be either ignored or unapplied if already applied. The original GRX 1 fna reader is also able to cope with mixed fna header and data, but I'm not going to implement this, it'll make the GRX 2 driver more complex and two times slower. E-gards: Jimmy

2 1

Patch for fd_win32.c
by Demmer, Thomas 19 Feb '03

19 Feb '03

Hi all, as promised, here are the patch files for MS Windows to use Device Independent Bimaps to speed up. This code is still a bit buggy, so you have been warned :-) As always, patches are against stock 2.4.5. Add the compiler switch -DUSE_DIB to your makefile to activate the DIB patches. * Changes: - In vdrivers/vd_win32.c: Forgot a call to GetObject() to map the bitmap into the process address space. - in fdrivers/fd_win32.c: Changed the access method from GDI Handles to bitmaps for BitBlt ram2video, video2ram and GetPixel(). Known Bugs: - GrWRITE and GrIMAGE are the same, the transparent color is ignored (TODO...) - There seems to be a small time window when the graphics window is not updated after it becomes visible. I noticed that once in speedtst, but was unable to reproduce that. Weird. Here are some measurements with speedtst: On my Laptop, without the readpixel patch, graphics window partly obscured, so some of the blts are too fast to be realistic: Driver readp drawp line hline vline block v2v v2r r2v SVGA24 320x 240 0.21 0.06 0.40 0.36 0.33 61.92 7.56 56.74 9.38 SVGA24 640x 480 0.21 0.06 0.43 0.40 0.37 62.01 6.66 35.82 9.67 RAM24 320x 240 6.99 9.52 10.51 134.95 11.18 161.74 99.51 0.00 0.00 RAM24 640x 480 5.92 7.31 6.26 57.76 4.44 58.91 31.75 0.00 0.00 A real test, with readpixel patch: Graphics driver: "win32" Driver readp drawp line hline vline block v2v v2r r2v SVGA24 640x 480 5.13 0.06 0.44 0.41 0.38 62.01 6.80 36.42 9.78 RAM24 640x 480 5.92 7.72 6.39 59.04 4.52 59.45 32.35 0.00 0.00 Same on my desktop. This one has a "natural" representation as 32-Bit Pixels, so some of the operations are actually slower. Graphics driver: "win32" Driver readp drawp line hline vline block v2v v2r r2v SVGA24 640x 480 3.93 0.10 2.02 8.97 2.72 94.39 1.16 75.10 27.64 RAM24 640x 480 4.91 3.97 7.84 122.14 4.97 105.13 71.22 0.00 0.00 On a sidenote: Is there a way to make the listserver ignore Outlook "Out-Of-Office Replies"? It is odd to (un)subscribe everytime I am on a trip, and I find these replies to lists stupid... Anyway, here are the patches, feedback welcome. <<grx20.pat.0128>> <<vd_win32.pat.0218>> <<fd_win32.pat.0218>> Ciao Tom Thomas Demmer Kraft Foods R&D Munich Phone: +49 89 62738-6302 Fax: +49 89 62738-86302 Thought of the Day: Certainly there are things in life that money can't buy, but it's very funny-- Did you ever try buying them without money? -- Ogden Nash

2 1

fna.txt: required clarification
by Dimitar Zhekov 17 Feb '03

17 Feb '03

ulpos in an ASCII font file is 0-based (unlike baseline). E-gards: Jimmy

1 0

Re: GrBitBlt is slow, MinGW32
by Demmer, Thomas 14 Feb '03

14 Feb '03

Sorry folks, been on a business trip without access to mail :-( The second call is for keeping the in-memory buffer up to date. One minor speed up would be just to do the call to the memory context, call InvalidateRect() and move the first call to the WindowProc. By now I have the r2v and v2r running for simply copying from RAM context to screen and back. They are quite fast and I am happy with them. As soon as I understand the fwdcopy_XXX() macros to handle the rest, I'll send a complete patch. Probable timing is next wednesday. Ciao Tom -----Original Message----- From: Eike Lange [mailto:eike.lange@uni-essen.de] Sent: Tuesday, February 11, 2003 2:51 PM To: 'GRX Mailing List' Subject: Re: GrBitBlt is slow, MinGW32 Hi! On Thu, Feb 06, 2003 at 12:48:05PM +0100, Demmer, Thomas wrote: > You can easily and quickly write to the RGB values from memory contexts. > If there is a way to quickly draw from a memory context to the hardware, I'd > prefer that, but I don't know. > > I'm still interested in this driver, and I'd like to colaborate, but I'm The framedriver for Linux (fd_xwin.c) just uses XCopyArea. The one for win32 (fd_win32.c) uses two BitBlt calls. Could we get rid of one of them? What is the second one for? Eike

1 0

Re: GrBitBlt is slow, MinGW32
by Josu Onandia 12 Feb '03

12 Feb '03

When a window gets partially or totally obscured or minimized, what you draw on it it's simply lost. When it gets unobscured the library has to repaint it. That's why the driver works with 2 bitmaps: one is the on-screen window and the other is an on-memory bitmap. Both are synchronized. When a part of the window gets visible it receives the message WM_PAINT it simply copies from the in-memory bitmap to the window. Perhaps XWindows makes this operation automatically, I don't know. But anyway I believe that the BitBlit operation is very fast. The problem in the driver is not the function bitblt, but the functions i_drawbitmap, bltv2r_8, and bltr2v_8, because they have to convert between a GR_frameRAM8 format and the Windows Bitmap format, and they do it one pixel at a time (SetPixel/GetPixel). I think that the suggestion of Thomas about using DeviceIndependentBitmaps is VERY interesting. Josu > -----Mensaje original----- > De: Eike Lange [SMTP:eike.lange@uni-essen.de] > Enviado el: martes 11 de febrero de 2003 14:51 > Para: 'GRX Mailing List' > Asunto: Re: GrBitBlt is slow, MinGW32 > > Hi! > > On Thu, Feb 06, 2003 at 12:48:05PM +0100, Demmer, Thomas wrote: > > You can easily and quickly write to the RGB values from memory contexts. > > If there is a way to quickly draw from a memory context to the hardware, > I'd > > prefer that, but I don't know. > > > I'm still interested in this driver, and I'd like to colaborate, but > I'm > > The framedriver for Linux (fd_xwin.c) just uses XCopyArea. The one for > win32 (fd_win32.c) uses two BitBlt calls. Could we get rid of one of > them? What is the second one for? > > Eike

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

Grx February 2003