Grx

grx@gnu.de

559 discussions

Re: GRX, gpc version 20060325, based on gcc-3.4.4 questions
by Maurice Lombardi 15 Nov '11

15 Nov '11

Le 14/11/2011 03:58, T.D. Telford a écrit : > I appreciate the test programs with grx, since the gpc documentation is > not great. > > Using grx, it appears that there is a flush problem, since the last item > to be displayed is not displayed. If a dummy item to be displayed is > executed, then the previous item is displayed. This seems to be true for > both text and graphical shapes. This is for bgi calls. ??? could you provide an example ? > My console programs use black text on a light yellow background. When I > run the bgi type programs, I get a graphics window and a console window, > with the latter having a black background and a light gray text, which > is not easy to read. Any suggestions? grx works mainly on the graphics window. It can simply restore the focus on the console window with RestoreCrtMode. To have full control of the console window you should use the crt unit. Please experiment with the attached testBGI program which uses both graph and crt. Parameters are for a mingw compiler, but it works also on DJGPP and on Linux X11 Basically it writes equivalents things with corresponding foreground and background colors, first in the graphics window, then in the console window. If you uncomment the RestoreCrtMode instruction in the middle, the window switches between graphics and console. Otherwise both windows are simultaneously visible. Please note the differences in writing the displayed parameters, using equivalent functions in both units. In addition: - Colors are prefixed with graph. and crt. to disambiguate, because both exist with the same name in both units. - In the console window background color turns from yellow to brown because the crt background color is limited to the first eight colors: this is to reproduce original BP BGI behavior. Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex 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

3 2

Re: GRX 2.4.8 yield patch
by Maurice Lombardi 12 Nov '11

12 Nov '11

Le 10/11/2011 22:12, borg(a)uu3.net a écrit : > First, please redownload the patch. > I added GrYield() in places you montioned long time ago. > (diff later in email). > > Okey, I will try to write small program to demostrate issue > when I will find some time. Not easy tho, because zeth > worked fine from time to time, and then had lag.. This is all > about race conditions here and there. > > % git diff HEAD^^^ HEAD^^ > diff --git a/src/mouse/w32keys.c b/src/mouse/w32keys.c > index 55ab4ee..9013cb2 100644 > --- a/src/mouse/w32keys.c > +++ b/src/mouse/w32keys.c > @@ -37,8 +37,10 @@ GrKeyType GrKeyRead(void) > int i, key; > > if (!_GrIsKbdEnabled()) { > - while (_nkeysw32pool< 1) > + while (_nkeysw32pool< 1) { > + GrYield(); > _GrUpdateInputs(); > + } > key = _keysw32pool[0]; > for (i = 0; i< _nkeysw32pool; i++) > _keysw32pool[i] = _keysw32pool[i + 1]; > @@ -51,6 +53,7 @@ GrKeyType GrKeyRead(void) > GrMouseEventEnable(1, 0); > } > for (;;) { > + GrYield(); > GrMouseGetEvent((GR_M_EVENT | GR_M_NOPAINT),&ev); > if (ev.flags& GR_M_KEYPRESS) { > return (ev.key); > OK adding this patch make the test programs which wait on GrKeyRead(), GrKeypressed() to work without any change. Exception is mousetst which waits for mouse events. But the correct behaviour is restored by replacing GrGetEventT and GrSleep in the waiting loop by GrGetEvent (without T i.e. no tempo) and GrYield, which is more consistent with your point of view. I would still be more convinced to introduce those inconsistent changes (needing changes in user's programs) if you could provide a test program which would enable a better justification for these changes. In fact I am convinced that there do are problems due to race conditions, because I see that a series of programs of mine which use the same graphical output module based on grx sometimes miss a refreshing of the screen with a new graphics, while running still correctly underneath, even printing correctly the new graphics. But this is not corrected by your changes, and I have not found the point until now. Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex 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

1 0

Re: GRX 2.4.8 yield patch
by Maurice Lombardi 08 Nov '11

08 Nov '11

Le 02/11/2011 19:13, borg(a)uu3.net a écrit : > YES! and thats what exacly im speaking about. > Honestly, GrMouseGetEventT() is quite fuzzy. > It is called in interfactive applications quite many times > and this exacly leads to problem im describing, because > GrMouseGetEventT() and _GrUpdateInputs() try to sleep > where they shouldnt, because they dont have idea what application > is actualy doing. Thats why GrYield() pops in, to handle > sleep where there is really no stuff to do (apps want to sleep and > GRX library have empty queue too). > > As speaking about painter issue, its simple. > WM_PAINT is called when any changes need to be repainted > and actual repain is done in Window Message thread. > Its pefectly ok, however, on SMP systems it is possible > that each thread runs on different CPU, so in fact they run > concurently. This means that WM_PAINT worker read from changeable > memory, and this leave artifacts on screen im speakng about. > > I tried to make those calls in sync with each other, but failed. > Either I had lag or excessive CPU usage that is not acceptable too. > > I added InvalidateRect(hGRXWnd,0,0) in GrYield() when there is no > stuff to do (app want to sleep and GRX queue is empty) > This little hack fixed it pefectly. No CPU load and no lag. The problem for me is that I have no example to be sure of what you say. I have tried to run several of my own programs, as well as the grx test programs, either with grx248 (with all patches contained in the "more things" section) and after appliying to it your patch, while looking to the task manager to see CPUs load. I first supposed that I had found the problem when seeing that in the test program compiled with your patch, but with no introduction of GrYield() in the calling program, the CPU load remained high when waiting for an input. When changing the wait instructions (GrReadkey() or a GrKeyPressed() loop usually in the test programs) to introduce a waiting loop with a GrYield() inside, it remained high, but when modifying GrYield() with your InvalidateRect() instruction above, the CPU load disappears. However when compiling with the original patched grx248, there is no CPU load when waiting in the original test programs (nor in my own programs which use more complex loops to catch both keyboard and mouse inputs). Running step by step with a gdb debugger (in fact insight, which is a graphics interfacing of gdb) I found that the problem came for the suppressing of the Sleep(1) instruction within DequeueW32Event(), which is there to enable to yield, seen as a refreshing of the graphics when it had been overwritten by moving an other window above it. I summary, can you provide to me a working minimal example program, may be based on one of the test programs, which displays your problems. Maurice BTW in my own programs I use GrMouseGetEvent without T, i.e. without tempo, in the waiting loop. -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex 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

1 0

Re: GRX 2.4.8 yield patch
by Maurice Lombardi 29 Oct '11

29 Oct '11

Le 13/10/2011 18:16, borg(a)uu3.net a écrit : > May I ask on what system you did the tests? XP sp3 on a dual core 2.2 GHz centrino duo laptop. > > I can say that I didnt noticed this problem of slowing down > until I upgraded. > On my previous configuration (Win2000, running on P3 800) zeth > (Doom Editor) was fast and worked very well. > After upgrade (Win2003 running on i5-760) I noticed strange slow downs. In fact I am embarassed and I cannot make my mind on what you say. You are right that some defects arise from the DOS roots of grx. For example you suppress Sleep(10) in GrMouseGetEventT() in w32inp.c. This garbles completely the way this function works. Its purpose is to wait until an event arrives or a maximum delay "tout" has elapsed. You suppress the delay. If you compare with the same function in dosinput.c you see that in both cases the function enter in an infinite loop. It exits either because an event is arrived meanwhile through an interrupt or because the maximum delay has occured. In DOS the delay is measured at the end of each loop through the function real_dtime(), and the loop blocks everything except interrupts meanwhile. In win32 the delay is measured in chunks of 10ms through Sleep(10) you have suppressed, rather than through an true measure of time, and this enables to yield meanwhile. This basically indicates some hesitation between a polling and an interrupt functioning of the program. The former, acceptable in DOS is catastrophic in windows. > > PS: I found another race condition in painter btw, leaving atrifacts > on screen. Again its SMP related and I fixed it. I dont like a fix > but again, it gave excelent results (no high CPU or lag). > I can share if interested... Certainly I am interested Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex 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

1 0

Re: GRX 2.4.8 yield patch
by Maurice Lombardi 13 Oct '11

13 Oct '11

Le 24/09/2011 13:39, borg(a)uu3.net a écrit : > Hello. > > I tried to subscribe to GRX ML but got strange reply > about unroutable address, so Im writing to you. There are indeed problems actually in hostings of gpc and grx > > I wrote a small patch to fix some issues with GRX lib on Win32 > for multiCPU platforms. > First, sometimes GRX gets lags around 100-200ms due to high > context switching (and probably some little race condition). > I noticed that there is 2 Sleep() in code around Mouse Events > and generic _W32EventQueue. Those Sleep() had impact on how > GRX lib peformed, so I removed them and added simple Event to handle > synchronization and CPU yield if nothing happens. > > diff is located here: > ftp://borg.uu3.net/home/borg/patch/grx-2.4.8-yield.patch > > I tried to add WaitForSingleObject() in DequeueW32Event() > but it performed very badly due to multiple calls to > _GrUpdateInput(). So I ended up adding GrYield() function > doing the wait. It should be used in main loop off application > to handle CPU effectivly. Not using it will not cause any problem > except excesive CPU usage. > > Please review this patch, any comments welcome. I am not sure I understand what you do. You define in vd_wind32.c and prototype in grx20.h a new function GrYield() to clear windowEvent which is set in EnqueueW32Event(), but you call GrYield() from nowhere. You seem to say above that you expect the end user of grx to clear it. This seems to me a bad idea for a general purpose graphics system: an end user has not to enter into such details, and very probably will never do it. As a check I have applied your patch and tried it. Nothing catastrophic, I just had to add a sleep in the demogrx program to slow down the animation which runs at the top of the main window to be able to read it. Not unexpected after elimination of sleeps in the mouse functions. But I can hardly see the interest. Have I missed something ? Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex 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

2 1

Batch drawing to memory only for less screen flickering
by jhliu 22 Dec '10

22 Dec '10

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

4 8

libmsvg
by Mariano 31 Oct '10

31 Oct '10

Hi, I have started libmsvg, a minimal and generic C library to read and write SVG files. It concentrates on a small subset of SVG to be useful. I plan to add later an interface to MGRX/GRX. Contributions are welcome. http://libmsvg.fgrim.com Greetings, M.Alvarez

1 0

Re: Quo vadis GRX?
by Frank Heckenbach 30 Jul '10

30 Jul '10

(This is a reply to a mail in the gpc(a)gnu.de list.) Thanks for bringing up GRX as well. Since it seems it is not used much apart from with GPC anymore, this is probably quite related. However, since GRX has its own mailing list (grx(a)gnu.de), I'm cross-posting and setting "Reply-To" there. Maurice Lombardi, the current GRX maintainer, should be reading both lists, and I hope he will comment. twixt(a)cstone.net wrote: > I would like to use Pascal to generate images in high resolution and at > least 24 bit color depth. There are links to a GRX library, which provides > 2d graphics, but the user manual there was last updated in 2007, which > suggests they are further behind than GPC. I don't find any grx library in > my Debian (Lenny) list of available packages, using the search feature > within aptitude. Apparently I would have to compile GRX and then somehow > get it to work with Pascal. As a barely capable programmer, I do not look > forward to this with glee. Compiling GRX, especially under Linux, should not be terribly difficult (try the docs first, then ask on the GRX list if necessary). However, it is a bit dated, only getting bug fixes and small changes for the last years (well, like GPC), and I suspect its future is dependent on GPC's future, too. I've used GRX for lightweight graphics progams (including some ported from BP, thanks to its "Graph" unit), but I'm not using it for any new projects now. For some high-performance graphics programs I did recently I used OpenGL (though in C++ -- AFAIK, there is no GPC interface available), which among other things supports hardware-accelerated graphics which is a must for high performance graphics today, and which GRX doesn't do AFAIK. > How about incorporating graphics > output directly in Pascal? Is there much interest in this? It seems to me > that it would make Pascal more attractive. I'd strongly suggest against that. In general, tying libraries tightly with languages is a bad idea IMHO. Of course, GPC has a set of runtime and add-on units, though actually rather small compared to other current environments; even more so in C -- libc contains rather basic stuff (and even it can be replaced, e.g. in OS kernels or emebdded systems), and all the higher-level libraries are not part of or specified by the language, but strictly users of the language. As a side note, that's IMHO a major reason for the success of C -- being library-neutral it can (not necessarily should) be used for just about anything. The same is true almost as well for C++ (STL mostly adds data structures and algorithms which do not depend on a certain environment) and to a slightly smaller degree for Pascal (in particular the I/O system, which is part of language, would have to be "cut out" in certain environments), but much less for Java and other languages that are dependent on big "frameworks". One reason why I think languages should not be coupled to libraries is that many kinds of libraries have a much shorter life cycle than programming languages (should have). The latter is measured in decades, the former often in years (at best). This is especially true of graphics, where we don't even a universally accepted standard today (let alone one that we could reasonably expect would still be the standard, say, 20 years from now) -- in my view, only OpenGL would be a candidate (if high-performance graphics is included; if not, there are various alternatives), but I'm sure others will disagree. Furthermore, as you can see from my comments, there's even a big difference stemming from which kind of graphics you want to support. Again, for high performance you need something that supports hardware acceleration; for simple graphics on cheap hardware, this can be a bad choice. E.g., though there exists a free software-implementation of OpenGL (Mesa), which works reasonably well IMHO (IOW, not too bad, but not perfect) on non-hardware-accelerated cards, but since it has to cater for the general case, simple things are often slower than in simpler libraries that specialize on such things. And of course, 2D graphics is quite different from 3D vector graphics which are both quite different from raytraced graphics. > It would be "like POVray > but even more powerful" as any general purpose programming language > naturally would be. Thanks for your time. This is also the case if you make it a stand-alone graphics library, which could then be driven from Pascal programs instead of POVray programs (if there's demand for it -- I don't know, I'm not much into raytracing). Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

Guaranteed Private Business Proposal
by William Wiredu 13 Jul '10

13 Jul '10

Attn Pls, I do hope this letter will not come to you as a surprise. It was borne out of my desire to share a mutual busines relationship with you. My name is DR. William Wiredu, a Ghanaian National. I work as the Director of Claims at the , ECONOMIC COMMUNITY OF WEST AFRICAN STATES[ ECOWAS] SAFETY HOUSE AND FINANCIAL SERVICES LTD., here in ACCRA- REPUBLIC OF GHANA GHANA. I got the information concerning you from the Ghana Chamber of Commerce, then i decided to contact you believing that , you will accept to be my partner in this business. Within this period, I have Watched with meticulous precision how African heads of states and Government functionaries have been using our firm to move huge sums of money USD,British Pound Sterling, Euro in (Cash) to their foreign partners. They bring in these consignments of money cash and secretly declare the contents as Jewelries, Gold, Diamond, and precious Stones, Family Treasure, Documents etc. Late Gen. Sani Abacha of Nigeria , Late Mobutu Sese Seko of Zaire , Laurent Kabila of Congo Democratic Republic , Foday Sanko of Sierra-Leone. Gen. Ibrahim Babangida of Nigeria,the immediate past president of Nigeria, Chief Olusegun Obasanjo etc. All these people have hundreds of consignments deposited with our safety company. Their foreign partners, friends and relatives are claiming most of the consignments. A lot of them are lying here unclaimed for the past ten years. No body may ever come for them because in most cases, the certificates of deposit are never available to any body except the depositors, most of them now dead. Sometime last year (2009), ECOWAS SAFETY HOUSE AND FUDICIAL SERVICES LTD. changed the procedure of claims of consignments. Now as soon as you are able to produce the secret information as contained in the secret file of any consignment, it will be released to you upon demand. From our records more than 120 consignments belonging to Gen. Abacha /Mobutu Sese Seko, have been claimed in the past six months. This is why I am soliciting for your co-operation and assistance. Late Gen Abacha has 25 consignments deposited with several names and codes. Six have been claimed in the past six months. Since he died, his first son also died in a plane crash, the second son is facing trial for murder and embezzlement, and the family members are under house arrest without communication. I have finished every arrangement for you to come and claim consignment tag No.1202BX containing US$ 10,000,000.00 and consignment tag No.1203BZ containing US$ 14,000,000.00. My duty is to supply you with all the required information and documents by e-mail phone and fax .You will deal directly with the management. The procedure is simple You will apply officially to the Director of Claims of ECOWAS SAFETY HOUSE AND FINANCIAL SERVICES, via the following security lines I will make avialable to you upon hearing from you,for the release of consignments No: 1202BX, and No: 1203BZ. They will demand some Documents and Secret codes. Call me I'll supply you with every detailed information and you will fax it to them. As soon as they confirm it to be correct. They will invite you for the Collection. If you do not want to come to Accra, you can arrange with them to transfer the consignment to anywhere on agreement. No body will ever know, I am the only person involved in the deal except the Lawyer who will write an agreement for us. I'll suggest upon conclusion we share the cash 50-50. At the successful conclusion of the deal, you will arrange for me and my family to come over to your country. I assure you that this deal has been hatched for years now. It is very secured and 100% risk free... Contact me immediately by E-mail For further explanation and directive on the procedure. And also your private telephone number. Awaiting your prompt response. DR. William Wiredu

1 0

$100 Donation for GRX20DVD (under DOS), required by MEdit (Vincenzo Morello)
by Mark Hunt 01 Jun '10

01 Jun '10

Note: I'm in/on the mailing list of GNU.DE. ========== Microsoft's Edit, as supplied in W98se, is a pretty good text editor. It handles laaaarrrg files. Under Windows, it permits one to use fonts of different sizes. MEdit, published as part of MGUI by Vincenzo Morello, is a graphic text editor. It's quite attractive - and *it* permits one to *also* use different font sizes - but *this under DOS*!!! See - http://web.tiscali.it/morello/MGui/demos.html The documentation for MEdit asserts that GRX20DVD (under DOS) is required. I can't find GRX20DVD *anywhere*. I'll donate $100 to the administrators of GNU.DE - payable via Paypal or by Western Union - for a copy of GRX20DVD (under DOS, a copy that'll permit MEdit to work correctly). I'll donate *even more* if somebody would like to work with Vincenzo's source code to *improve* MEdit (under DOS). Thanks. Mark.

2 2

← Newer
1
2
3
4
5
6
7
8
...
56
Older →

Jump to page:

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