Dear Sir,
Sorry for the bothering and hope to get any help.
For drawing speed and less screen flickering reason, is there any way in GRX to do drawings to memory only, and then update to screen (video) at one time after all drawings was done ? I tried to do it by context functions but not succeeded. Thanks in advanced.
Best Regards,
jhliu
Le 09/12/2010 08:20, jhliu a écrit :
For drawing speed and less screen flickering reason, is there any way in GRX to do drawings to memory only, and then update to screen (video) at one time after all drawings was done ? I tried to do it by context functions but not succeeded.
Short answer: This possibility exists now only for some 16 and 256 colors VESA driver modes in DJGPP for the BGI emulation (it existed in BP). It depends on some VESA functions of the video card, and may depend somewhat on the quality of VESA support of the card. To check, run the test/bgi/bccbgi test program, after setting e.g. # set GRX20DRV=VESA gw 1280 gh 1024 nc 256 # bccbgi The third line of the status is Available pages : 2 (if good, 1 otherwise)
When running the (third) test GetImage / PutImage demonstration, it runs twice, the first without / the second with 2 pages support (if it exists)
Long answer: I have to investigate for possibilities. Don't held your breath ...
Maurice
El 10/12/10 10:24, Maurice Lombardi escribió:
Le 09/12/2010 08:20, jhliu a écrit :
For drawing speed and less screen flickering reason, is there any way in GRX to do drawings to memory only, and then update to screen (video) at one time after all drawings was done ? I tried to do it by context functions but not succeeded.
Short answer: This possibility exists now only for some 16 and 256 colors VESA driver modes in DJGPP for the BGI emulation (it existed in BP). It depends on some VESA functions of the video card, and may depend somewhat on the quality of VESA support of the card. To check, run the test/bgi/bccbgi test program, after setting e.g. # set GRX20DRV=VESA gw 1280 gh 1024 nc 256 # bccbgi The third line of the status is Available pages : 2 (if good, 1 otherwise)
When running the (third) test GetImage / PutImage demonstration, it runs twice, the first without / the second with 2 pages support (if it exists)
Long answer: I have to investigate for possibilities. Don't held your breath ...
Maurice
There is an example of a general solution in the demogrx test program. The running banner is drew in a memory context and them bitblt to the screen (see the paint_animation function).
Greetings Mariano
Le 10/12/2010 17:56, Mariano a écrit :
El 10/12/10 10:24, Maurice Lombardi escribió:
Le 09/12/2010 08:20, jhliu a écrit :
There is an example of a general solution in the demogrx test program. The running banner is drew in a memory context and them bitblt to the screen (see the paint_animation function).
Indeed, this is the way the "saucer" is drawn in the GetImage / PutImage demo in the bgi/bccbgi program, when multiple paging is not available, i.e. in all cases except some VESA/DJGPP modes. See the sources in src/bgi/getimage.c. I was supposing that the OP had in mind a common practice in slow systems in the old times: There are two pages in memory and the "visual page" is switched between the two nearly instantaneously (in fact at the start of the next refreshing of the screen). This is why it exists only in the old DOS system VESA/DJGPP. In modern times the drawing is made in memory in a minimal rectangle (not the whole screen), and the actual refreshing is deferred to the Windows system through an InvalidateRect() function (or to the X11 system through an PIXEL_CACHE_INVALIDATE() macro). I am not sure there is really an advantage in the old way of doing without availability of the special card function.
Maurice
Dear Maurice,
Thanks for your answer, I will follow your suggestions and do some tests.
Regards,
JH
----- Original Message ----- From: "Maurice Lombardi" Maurice.Lombardi@ujf-grenoble.fr To: grx@gnu.de Sent: Saturday, December 11, 2010 7:25 PM Subject: Re: Batch drawing to memory only for less screen flickering
Le 10/12/2010 17:56, Mariano a écrit :
El 10/12/10 10:24, Maurice Lombardi escribió:
Le 09/12/2010 08:20, jhliu a écrit :
There is an example of a general solution in the demogrx test program. The running banner is drew in a memory context and them bitblt to the screen (see the paint_animation function).
Indeed, this is the way the "saucer" is drawn in the GetImage / PutImage demo in the bgi/bccbgi program, when multiple paging is not available, i.e. in all cases except some VESA/DJGPP modes. See the sources in src/bgi/getimage.c. I was supposing that the OP had in mind a common practice in slow systems in the old times: There are two pages in memory and the "visual page" is switched between the two nearly instantaneously (in fact at the start of the next refreshing of the screen). This is why it exists only in the old DOS system VESA/DJGPP. In modern times the drawing is made in memory in a minimal rectangle (not the whole screen), and the actual refreshing is deferred to the Windows system through an InvalidateRect() function (or to the X11 system through an PIXEL_CACHE_INVALIDATE() macro). I am not sure there is really an advantage in the old way of doing without availability of the special card function.
Maurice
-- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr from January 1st, 2011, the Laboratoire de Spectrométrie Physique will become the LABORATOIRE INTERDISCIPLINAIRE DE PHYSIQUE (LIPhy).
Grx mailing list Grx@gnu.de https://www.g-n-u.de/mailman/listinfo/grx
Dear Sir,
After following suggestions from Maurice and Mariano Sirs, I have the following pascal codes seems to meet my requirements:
TYPE pGrContext=^GrContext; VAR scrgrc,bufgrc:pGrContext; BEGIN GrSetDriver("memory gw 640 gh 400 nc 256"); GrSetMode(GR_default_graphics,2,3,4,5,6); scrgrc:=GrCurrentContext; bufgrc:=GrCreateContext(GrMaxX,GrMaxY,NIL,NIL);
line(GrMaxX,GrMaxY,0,0); line(GrMaxX,0,0,GrMaxY);
{ copy whole screen context to bufgrc } GrBitBltNC(bufgrc,0,0,NIL,0,0,GrMaxX,GrMaxY,GrWRITE); { set new drawings to bufgrc } GrSetContext(bufgrc); line(0,GrMaxY DIV 2,GrMaxX,GrMaxY DIV 2); line(GrMaxX DIV 2,0,GrMaxX DIV 2,GrMaxY);
ClearDevice; GrSetContext(scrgrc); { copy bufgrc back to screen } GrBitBltNC(NIL,0,0,bufgrc,0,0,GrMaxX,GrMaxY,GrWRITE);
CloseGraph; END.
The 3rd and 4th 'line' commands seems to be drew in the memory and then be displayed at the next 'GrSetContext' and 'GrBitBltNC' commands. But the remaining problem is the 'GrBitBltNC' takes about 0.1~0.2 seconds on my Linux system, is there any other alternate method to speed-up this ?
Regards,
JH
----- Original Message ----- From: "Maurice Lombardi" Maurice.Lombardi@ujf-grenoble.fr To: grx@gnu.de Sent: Saturday, December 11, 2010 7:25 PM Subject: Re: Batch drawing to memory only for less screen flickering
Le 10/12/2010 17:56, Mariano a écrit :
El 10/12/10 10:24, Maurice Lombardi escribió:
Le 09/12/2010 08:20, jhliu a écrit :
There is an example of a general solution in the demogrx test program. The running banner is drew in a memory context and them bitblt to the screen (see the paint_animation function).
Indeed, this is the way the "saucer" is drawn in the GetImage / PutImage demo in the bgi/bccbgi program, when multiple paging is not available, i.e. in all cases except some VESA/DJGPP modes. See the sources in src/bgi/getimage.c. I was supposing that the OP had in mind a common practice in slow systems in the old times: There are two pages in memory and the "visual page" is switched between the two nearly instantaneously (in fact at the start of the next refreshing of the screen). This is why it exists only in the old DOS system VESA/DJGPP. In modern times the drawing is made in memory in a minimal rectangle (not the whole screen), and the actual refreshing is deferred to the Windows system through an InvalidateRect() function (or to the X11 system through an PIXEL_CACHE_INVALIDATE() macro). I am not sure there is really an advantage in the old way of doing without availability of the special card function.
Maurice
-- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr from January 1st, 2011, the Laboratoire de Spectrométrie Physique will become the LABORATOIRE INTERDISCIPLINAIRE DE PHYSIQUE (LIPhy).
Grx mailing list Grx@gnu.de https://www.g-n-u.de/mailman/listinfo/grx
Le 14/12/2010 03:15, jhliu a écrit :
The 3rd and 4th 'line' commands seems to be drew in the memory and then be displayed at the next 'GrSetContext' and 'GrBitBltNC' commands. But the remaining problem is the 'GrBitBltNC' takes about 0.1~0.2 seconds on my Linux system, is there any other alternate method to speed-up this ?
You seem to have a speed problem on your (old ?) machine.
I have currently no direct access to a linux system, because I am out of lab. I have a (4 year old) laptop, centrino duo 2.2 Ghz, nVidia Quadro FX 1500M graphics card, with Windows XP. On it I have installed both a djgpp and a mingw32 system, and compliled grx on both. main gcc is 4.4.4 (djgpp) 4.5.0 (mingw) (grx 2.4.8 with all patches is compiled with it) gpc is 20070904 with 3.4.4 backend (djgpp) and 3.4.5 backend (mingw) I run the following gpc program, which is an adaptation of yours: pure grx instead of mixed graph and grx, time measurement, and a 1000x loop over the second GrBitBlt to have measurable times --------------------------------------------------------------------- program page2(input); {$X+} uses gpc,grx;
VAR scrgrc,bufgrc:GrContextPtr; t1,t2:UnixTimeType; ms1,ms2:CInteger; i:integer; msg: string(80); BEGIN GrSetDriver('win32 gw 640 gh 480 nc 256'); GrSetMode(GR_default_graphics,0,0,0,0,0);
scrgrc:=GrScreenContext; bufgrc:=GrCreateContext(GrMaxX,GrMaxY,NIL,NIL);
GrLine(GrMaxX,GrMaxY,0,0,GrWhite); GrLine(GrMaxX,0,0,GrMaxY,GrWhite); GrKeyRead;
{ copy whole screen context to bufgrc } GrBitBlt(bufgrc,0,0,NIL,0,0,GrMaxX,GrMaxY,GrWRITE);
{ clear screen } GrClearScreen(GrBlack); GrKeyRead;
{ set new drawings to bufgrc } GrSetContext(bufgrc); GrLine(0,GrMaxY DIV 2,GrMaxX,GrMaxY DIV 2,GrWhite); GrLine(GrMaxX DIV 2,0,GrMaxX DIV 2,GrMaxY,GrWhite);
{ copy bufgrc back to screen } GrSetContext(scrgrc); t1:=GetUnixTime(ms1); for i:=1 to 1000 do GrBitBlt(NIL,0,0,bufgrc,0,0,GrMaxX,GrMaxY,GrWRITE); t2:=GetUnixTime(ms2);
WriteStr(msg,(t2-t1)+(ms2-ms1)/1e6); GrTextXY(0, GrMaxY div 2,msg,grWhite,GrBlack); GrKeyRead;
END. ----------------------------------------------------------------------------- I compile without any optimisation (no -Ox) The only change is the driver name in GrSetDriver
The times are for _one_ GrBitBlt
Win32 0.106 milliseconds VESA 6 milliseconds STDVGA 15 milliseconds
Furthermore I can compile and run on a lab machine (64 bits) with linux (Fedora Core) through a VNC I get there XWIN 0.78 milliseconds
So your times are much too longer. For that reason I suppose you have a very slow machine/ graphics card.
The only remedy I can imagine is to use the two pages mechanism available with VESA, implemented ib graph/BGI. But I do not know how to access the VESA functions on a linuw system, and I have currently no access to such a system.
Maurice
Dear Maurice Sir,
I tried the test program on my another Fedora machine, that's a 2.93GHz Core 2 Dou E7500 CPU with nVidia GeForce 7050 graphics card, but the result is also much slower than yours too:
1. First GrBitBltNC for copy screen context to bufgrc: 0.04 secs 2. 1000 times GrBitBltNC to copy bufgrc back to screen: 10.27 secs.
But I have the following changes compares to yours:
1. The GrSetDriver is changed to GrSetDriver('win32 gw 1024 gh 768 nc 65536'), that creates a bigger window and color depth that I will need. From my test, it is about 3X slow down than GrSetDriver('win32 gw 640 gh 480 nc 256');
2. I don't install djgpp and mingw on my system, and I use the following gpc commands: gpc --automake \ -o ./page2 page2.pp \ -L/usr/local/grx248/lib/unix \ -L/usr/X11R6/lib \ -L/usr/local/grx248/pascal \ -L/usr/local/grx248/lib/unix/libgrx20X.a \ -lgrx20X -lX11 -lm
This gpc command works fine on both my Linux and Sun Solaris machines.
I'm guessing, is the problem comes from the difference of djgpp/mingw/X11 ?
Regards,
JH
----- Original Message ----- From: "Maurice Lombardi" Maurice.Lombardi@ujf-grenoble.fr To: "jhliu" jhliu@ms2.hinet.net Cc: grx@gnu.de Sent: Saturday, December 18, 2010 4:54 AM Subject: Re: Batch drawing to memory only for less screen flickering
Le 14/12/2010 03:15, jhliu a écrit :
The 3rd and 4th 'line' commands seems to be drew in the memory and then be displayed at the next 'GrSetContext' and 'GrBitBltNC' commands. But the remaining problem is the 'GrBitBltNC' takes about 0.1~0.2 seconds on my Linux system, is there any other alternate method to speed-up this ?
You seem to have a speed problem on your (old ?) machine.
I have currently no direct access to a linux system, because I am out of lab. I have a (4 year old) laptop, centrino duo 2.2 Ghz, nVidia Quadro FX 1500M graphics card, with Windows XP. On it I have installed both a djgpp and a mingw32 system, and compliled grx on both. main gcc is 4.4.4 (djgpp) 4.5.0 (mingw) (grx 2.4.8 with all patches is compiled with it) gpc is 20070904 with 3.4.4 backend (djgpp) and 3.4.5 backend (mingw) I run the following gpc program, which is an adaptation of yours: pure grx instead of mixed graph and grx, time measurement, and a 1000x loop over the second GrBitBlt to have measurable times
program page2(input); {$X+} uses gpc,grx;
VAR scrgrc,bufgrc:GrContextPtr; t1,t2:UnixTimeType; ms1,ms2:CInteger; i:integer; msg: string(80); BEGIN GrSetDriver('win32 gw 640 gh 480 nc 256'); GrSetMode(GR_default_graphics,0,0,0,0,0);
scrgrc:=GrScreenContext; bufgrc:=GrCreateContext(GrMaxX,GrMaxY,NIL,NIL);
GrLine(GrMaxX,GrMaxY,0,0,GrWhite); GrLine(GrMaxX,0,0,GrMaxY,GrWhite); GrKeyRead;
{ copy whole screen context to bufgrc } GrBitBlt(bufgrc,0,0,NIL,0,0,GrMaxX,GrMaxY,GrWRITE);
{ clear screen } GrClearScreen(GrBlack); GrKeyRead;
{ set new drawings to bufgrc } GrSetContext(bufgrc); GrLine(0,GrMaxY DIV 2,GrMaxX,GrMaxY DIV 2,GrWhite); GrLine(GrMaxX DIV 2,0,GrMaxX DIV 2,GrMaxY,GrWhite);
{ copy bufgrc back to screen } GrSetContext(scrgrc); t1:=GetUnixTime(ms1); for i:=1 to 1000 do GrBitBlt(NIL,0,0,bufgrc,0,0,GrMaxX,GrMaxY,GrWRITE); t2:=GetUnixTime(ms2);
WriteStr(msg,(t2-t1)+(ms2-ms1)/1e6); GrTextXY(0, GrMaxY div 2,msg,grWhite,GrBlack); GrKeyRead;
END.
I compile without any optimisation (no -Ox) The only change is the driver name in GrSetDriver
The times are for _one_ GrBitBlt
Win32 0.106 milliseconds VESA 6 milliseconds STDVGA 15 milliseconds
Furthermore I can compile and run on a lab machine (64 bits) with linux (Fedora Core) through a VNC I get there XWIN 0.78 milliseconds
So your times are much too longer. For that reason I suppose you have a very slow machine/ graphics card.
The only remedy I can imagine is to use the two pages mechanism available with VESA, implemented ib graph/BGI. But I do not know how to access the VESA functions on a linuw system, and I have currently no access to such a system.
Maurice
-- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr from January 1st, 2011, the Laboratoire de Spectrométrie Physique will become the LABORATOIRE INTERDISCIPLINAIRE DE PHYSIQUE (LIPhy).
Le 21/12/2010 04:11, jhliu 劉錦浩@hinet a écrit :
Dear Maurice Sir,
I tried the test program on my another Fedora machine, that's a 2.93GHz Core 2 Dou E7500 CPU with nVidia GeForce 7050 graphics card, but the result is also much slower than yours too:
- First GrBitBltNC for copy screen context to bufgrc: 0.04 secs
How do you measure that ? time for a single copy is too short, and presumably fooled by overheads. I had introduced the x1000 loop and the GetUnixTimes in the opposite GrBitBlt to have significant measures.
- 1000 times GrBitBltNC to copy bufgrc back to screen: 10.27 secs.
This seems reasonable: I measure 3 secs for the same GrBitBlt with the xwin driver (2.5 secs with the sdl driver) (and your gw gh nc values below). This gives 3 milliseconds for a single copy from buf to screen. Seems OK ? The refreshing time for the screen is usually between 60Hz and 100Hz.
But I have the following changes compares to yours:
- The GrSetDriver is changed to GrSetDriver('win32 gw 1024 gh 768 nc
65536'), that creates a bigger window and color depth that I will need.
my 3 secs is for these parameters. win32 (the mingw driver) should be replaced by xwin for X11, but this is unimportant because GrSetDriver falls back to the default driver (xwin under X11) when not finding win32.
From my test, it is about 3X slow down than GrSetDriver('win32 gw 640 gh 480 nc 256');
for win32 in my case I go from 0.1 millisec to 3 millisec for xmin, I go from 0.8 millisec to 3 millisec: basically same as yours
I'm guessing, is the problem comes from the difference of djgpp/mingw/X11 ?
for me DJGPP/VESA is much slower than X11 and X11 is somewhat slower than mingw (but it is on a different computer, accessed through a VNC) I suppose that you are directly on your computer: with a xterm it is catastrophically slow.
Maurice
-
jhliu -
jhliu 劉錦浩＠hinet
-
Mariano -
Maurice Lombardi