[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with Gorm

From: Fred Kiefer
Subject: Re: Problem with Gorm
Date: Mon, 04 Jul 2011 10:41:35 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv: Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10

Which backend are you using? That will result in different methods being called next and most likely the problem is one level deeper.

I had a quick look into these new methods and didn't like too much what I saw there. We have a lot of code duplication between these two methods, but we also have differences there which I don't understand. Why do we use scaling for the native drawing but not for the gui drawing? Anyway, the code in native drawing should not check for isDrawingToScreen. When drawing to a PDF or PostScript surface we should be able to composite or dissolve, we just need to package that up correctly as backend operations. And of course need to have the PS and PDF context report back that they are able to support this.

I also noticed that the new code wont fill the cached image rep with the image background colour. Why isn't this done and does this match the Cocoa behaviour? Why does the old code (guiDrawInRect:...) use PSgsave and PSgrestore around the cache drawing? We wont do any other operations on the cache and don't need to restore the old state.

I think that we should start a discussion about this whole drawing code. Hopefully we end up with a deeper understanding of what should happen here and will then be able to package it up with a nice and clean call to the backend and three or four (almost?) correct implementations for this in GSContext, GSStreamContext and GSCairoContext. But then I may be completely wrong here, as I really don't understand much of this new code.

On 03.07.2011 01:49, Germán Arias wrote:
Well, after compiling gui with "debug=yes" all works fine. But then,
recompiling gui just with "make" the problem is there again.

On sáb, 2011-07-02 at 11:36 -0600, Eric Wasylishen wrote:
Hey German,
I wasn't able to reproduce that in Gorm or Gemas, but it looks like it's coming 
from code I've worked on lately...
Frame 1 of the backtrace is just the line which redirects -drawInRect: to 
-guiDrawInRect:, but frame 0 has no debug info. Would you be able to recompile 
-gui (and maybe -back as well) with debugging on (just make clean and make 
debug=yes), and see if it you can get a better backtrace? Thanks.

On 2011-07-01, at 4:20 PM, Germán Arias wrote:

When I select "Containers Palette" the app crash. The backtrace is:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb669fb30 (LWP 6463)]
0x0847ac03 in ?? ()
(gdb) backtrace
#0  0x0847ac03 in ?? ()
#1  0xb7344734 in -[NSImage drawInRect:fromRect:operation:fraction:] (
    self=0x86385f8, _cmd=0xb759a358, dstRect=
        {origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
        {origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
    op=NSCompositeSourceOver, delta=1) at NSImage.m:1297
#2  0xb73405dd in -[NSImage drawAtPoint:fromRect:operation:fraction:] (
    self=0x86385f8, _cmd=0xb759a320, point={x = 0, y = 0}, srcRect=
        {origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
    op=NSCompositeSourceOver, delta=1) at NSImage.m:925
#3  0xb7344650 in -[NSImage
compositeToPoint:fromRect:operation:fraction:] (
    self=0x86385f8, _cmd=0xb759a2d0, aPoint={x = 0, y = 9}, srcRect=
        {origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
    op=NSCompositeSourceOver, delta=1) at NSImage.m:864
#4  0xb73402a1 in -[NSImage compositeToPoint:operation:]
    _cmd=0xb756f658, aPoint={x = 0, y = 9}, op=NSCompositeSourceOver)
    at NSImage.m:811
#5  0xb72df7dc in -[NSCell drawInteriorWithFrame:inView:]
    _cmd=0xb756f668, cellFrame=
        {origin = {x = 0, y = 0}, size = {width = 9, height = 9}},
    controlView=0x86393f0) at NSCell.m:2031
#6  0x086385f8 in ?? ()
#7  0xb756f658 in _OBJC_SELECTOR_TABLE ()
   from /usr/GNUstep/Local/Library/Libraries/
---Type<return>  to continue, or q<return>  to quit---
#8  0x00000000 in ?? ()

FisicaLab also crash, when you open the help panel, with a similar

reply via email to

[Prev in Thread] Current Thread [Next in Thread]