Grx

grx@gnu.de

559 discussions

GRX23/SOL2.6 with only 8 bpp.
by Alessandro Moure 12 Nov '99

12 Nov '99

Hi. I don't know why but when I run xmodetest it only returns 8 bpp modes. My system is Sparc Ultra10/Creator, with Solaris 2.6. When setting the driver I use: GrSetDriver("XWIN"); If I use XWIN1,4,8,16 or 24 the code says it cannot find the driver. Is there any special setting to do? I've downloaded the patch, but I think I messed up with the + (add), -(delete) and ! (???) stuff. Also, some of the files referred in the patch have diff dates from the files I've just downloaded from GRX site. Why? Please excuse my poor english and thank you in advance. Alessandro Moure Laboratory of Computed Tomography CEFET-PR - Brazil

1 0

(no subject)
by Karel Dusek 05 Nov '99

05 Nov '99

unsubscribe grx dusekk(a)student.fsid.cvut.cz

1 0

(no subject)
by Michal Stencl 21 Oct '99

21 Oct '99

Hello, I'm Michal Stencl and I agree with new GRX licence at all. Bye.

1 0

Re: GRX license
by Michael Goffioul 18 Oct '99

18 Oct '99

I agree. I'll send the paper as soon as possible. -- Michaël Goffioul EMIC - UCL Batiment Maxwell Place du Levant, 3 B-1348 Louvain-la-Neuve Belgium Tel.: +32 10 47 23 15 Fax.: +32 10 47 87 05

1 0

RE: GRX licence
by Gary Sands 18 Oct '99

18 Oct '99

I have no problems with this and 3dfx don't seem to care either. -----Original Message----- From: Hartmut Schirmer [mailto:hartmut.schirmer@arcormail.de] Sent: 17 October 1999 10:06 To: csaba(a)vuse.vanderbildt.edu; pavenis(a)lanet.lv; goffioul(a)emic.ucl.ac.be; Sven(a)rufus.central.de; stenclpmd(a)bratislava.telecom.sk; hahn(a)itpaxp5.physik.uni-karlsruhe.de; ulrich(a)lab1.psy.univie.ac.at Cc: grx(a)gnu.de; peter(a)gerwinski.de Subject: GRX licence Hi everyone, there are plans about changing the GRX licence. It´s now under LGPL with an exception for DOS. Several people (me, Csaba, Peter Gerwinski) thought about changing this. <<SNIP>>

1 0

Second Proposal(RE: A memory leak?)
by WATANABE AKIRA 17 Oct '99

17 Oct '99

> Hope I could made it somewhat clearer ... Thank you for your helpfull sugestion. > The frame memory is passed from the cwork context to the > result pixmap. I understanded that: 1)My last proposal for a bug fixing is wrong, because valiable result has frame memory same cwork's. 2)Below functions of the create/destroy functions are pairs; + GrCreateContext(),... vs GrDestroyContext() + GrBuildPixmapFromBits(),... vs GrDestroyPattern() So, when users call GrBuildPixmapFromBits(..,..,NULL,[NULL]), they must take care about the allocated memory; cf. calling GrDestroyPattern() But, I think that GrDestroyPattern can not free the memory created by GrBuildPixmapFromBits() completely. Oliginal source : Oliginal code can free a top of the frame memory area only. void GrDestroyPattern(GrPattern *p) { if(p->gp_ispixmap) { if(p->gp_pxp_source.gf_memflags & GCM_MYMEMORY) farfree(p->gp_pxp_source.gf_baseaddr); if(p->gp_pxp_source.gf_memflags & GCM_MYCONTEXT) free(p); return; } if(p->gp_bitmap.bmp_memflags) free(p); } Modified source : Folowing code is modified that it will free all planes of the frame memory. void GrDestroyPattern(GrPattern *p) { if(p->gp_ispixmap) { if(p->gp_pxp_source.gf_memflags & GCM_MYMEMORY){ // 991012 int ii = p->gp_pxp_source.gf_driver->num_planes; // 991012 while(--ii >= 0) farfree(p->gp_pxp_source.gf_baseaddr[ii]); // 991012 } // c991012 if(p->gp_pxp_source.gf_memflags & GCM_MYMEMORY) // c991012 farfree(p->gp_pxp_source.gf_baseaddr); if(p->gp_pxp_source.gf_memflags & GCM_MYCONTEXT) free(p); return; } if(p->gp_bitmap.bmp_memflags) free(p); } What do you think about above code? Akira Watanabe

3 3

A memory leak?
by Uncle(Akira Watanabe) 11 Oct '99

11 Oct '99

Hello GRX freaks, I think that GRX is good library and very usefull. Bug in GrBuildPixmapFromBits() of GRX2.2 and 2.3 found ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This problem is a memory leak. In GrBuildPixmapFromBits(), a temporaly context area is allocated from the heap-area by GrCreateContext(). But,the temporaly area isn't deallocated after this and the area is missing by the application program, because the "cwork" variable is a Auto-variable, and is destroyed at the end of this function. When you have a large memory or call this function at a few times by a your program running, this bug dose not cause the abnomal excution of the program. The GrBuildPixmapFromBits() function is found in makepat.c Fixing the bug is easy, the following source in src/pattern/makepat.c: (I added the ~~~~~~-line part in the follow.) GrPattern *GrBuildPixmapFromBits(char *bits,int w,int h,GrColor fgc,GrColor bgc) { GrContext csave,cwork; GrPixmap *result; unsigned char *src; int wdt,wdt2,fullw; int hgt,mask,byte; if((fullw = _GrBestPixmapWidth(w,h)) <= 0) return(NULL); result = (GrPixmap *)malloc(sizeof(GrPixmap)); if(result == NULL) return(NULL); if (!GrCreateContext(fullw,h,NULL,&cwork)) { // "NULL" means that internal area is secured free(result); return NULL; } csave = *CURC; *CURC = cwork; fgc &= C_COLOR; bgc &= C_COLOR; for(hgt = 0; hgt < h; hgt++) { for(wdt2 = fullw; (wdt2 -= w) >= 0; ) { src = (unsigned char *)bits; mask = byte = 0; for(wdt = w; --wdt >= 0; ) { if((mask >>= 1) == 0) { mask = 0x80; byte = *src++; } (*CURC->gc_driver->drawpixel)(wdt2+wdt,hgt,((byte & mask) ? fgc : bgc)); } } bits += (w + 7) >> 3; } *CURC = csave; result->pxp_source = cwork.gc_frame; result->pxp_source.gf_memflags = (GCM_MYCONTEXT | GCM_MYMEMORY); result->pxp_ispixmap = TRUE; result->pxp_width = fullw; result->pxp_height = h; result->pxp_oper = 0; GrDestroyContex(&cwork); // 990923 added by A.Watanabe. // ~~~~~~~~~~~~~~~~~~~~~~~*----The above line added. return((GrPattern *)result); } ------------- * ------------ Do you think that my pointing out a bug is correct? with greetings, Akira Watanabe _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Akira Watanabe A Electronics Engineer in a motor company

2 3

(no subject)
by Leonardo Alejandro Bustos Wallace 27 Sep '99

27 Sep '99

Hi! I worked some years whith Borland C 3.0, and now I change with gcc compiler. The problem that I have is to install the grx libraries. I compile the grx23 librearies, but when I wrote C:\djgpp\contrib\grx23\src>make -f makefile.dj2 ... utils/shiftscl.c: In function '_GR_shift_scanline': utils/shiftscl.c:48: Invalid 'asm' statement: utils/shiftscl.c:48: fixed or forbidden register 2 (cx) was spilled for class CREG. utils/shiftscl.c:102: Invalid 'asm' statement: utils/shiftscl.c:102: fixed or forbidden register 2 (cx) was spilled for class CREG. make.exe[1]: *** [utils/shiftscl.o] Error 1 C:\djgpp\contrib\grx23\src>_ Of the rest, I do it well I think.(twice) Can someone help me ? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Mailing list archive available online
by Anja Drewitz 27 Sep '99

27 Sep '99

Hello, now you can access the grx and grx-announce mailing list archives via the world wide web: http://www.gnu.de/archive/wilma.cgi/grx http://www.gnu.de/archive/wilma.cgi/grx-announce Currently, the archive dates back to June 1999 only. We are going to put earlier messages online, too, as time permits. (Note: I mentioned the grx-announce archive is mentioned for sake of completeness only as it contains no messages yet.) Best wishes, Anja

1 0

Bug report
by Josu Onandia 09 Sep '99

09 Sep '99

Hello, I'm evaluating the GRX library (a very good work, by the way) and I believe I've found two bugs. The function _GrBuildFont (file buildfnt.c) test the bit GR_FONTCVT_FIXIFY that way: if((cvt & GR_FONTCVT_FIXIFY) & fprop) and I believe it should look if((cvt & GR_FONTCVT_FIXIFY) && fprop) ---- Then the function cvtbitmap (same file) allocates a buffer (called 'work') but before the code reaches the FREE(work) sentence, the pointer 'work' is modified, and FREE crashes. I've solved this way: savework = work = ALLOC((size_t)i); .... .... // FREE(work); FREE(savework); End of bug report. I hope this information will be useful to you. Now a question: I'm trying to convert a proportional font into a fixed one: pFont = GrLoadFont("tms38"); pFontFix = GrBuildConvertedFont(pFont,GR_FONTCVT_FIXIFY,38,38,0,0); With the corrections above now it works, at least it doesn't crash, but the resulting font, when printed, looks very strange. Am I doing something wrong? Thanks. Josu

2 1

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