Home > Archive > Smalltalk > July 2007 > VW GraphicsContext copy
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
VW GraphicsContext copy
|
|
| lopemanc@swbell.net 2007-07-09, 7:10 pm |
| Hi All,
I just ran into an issue recently that I resolved by changing a
GraphicsContext copy to get a new one from the print job. Yet running
the same code (with the copy) against a the screen CG yields valid
results. I know at one time using GC copy had issues. Does anybody
know if these issues have been resolve? I was surprised to find that
GraphicsContext does so little int he postCopy. What can you mess
with in a copied GC safely? And does that differ from Screen GC to
HostPrinter GC to Postscscript GC?
Thanks,
Chris
| |
| Eliot Miranda 2007-07-09, 7:10 pm |
| lopemanc@swbell.net wrote:
> Hi All,
>
> I just ran into an issue recently that I resolved by changing a
> GraphicsContext copy to get a new one from the print job. Yet running
> the same code (with the copy) against a the screen CG yields valid
> results. I know at one time using GC copy had issues. Does anybody
> know if these issues have been resolve? I was surprised to find that
> GraphicsContext does so little int he postCopy. What can you mess
> with in a copied GC safely? And does that differ from Screen GC to
> HostPrinter GC to Postscscript GC?
Hi Chris,
AFAIR an image-level GC is just a container and doesn't have any
associated state in the VM except for one or two WM-level GCs cached by
the VM. To do a graphics operation the VM inspects the image-level GC's
inst vars. If they match the cache then the VM will use its cached
WM-level GC. If not, it'll create a new WM-level GC, initialize it form
the image-level GC, perform the operation and then cache the WM-level
GC. So effectively the image-level GC doesn't have any associated
hidden state, hence you should be able to copy it freely.
--
The surest sign that intelligent life exists elsewhere in Calvin &
the universe is that none of it has tried to contact us. Hobbes.
--
Eliot ,,,^..^,,, Smalltalk - scene not herd
| |
| lopemanc@swbell.net 2007-07-09, 10:09 pm |
| On Jul 9, 3:47 pm, Eliot Miranda <eli...@pacbell.net> wrote:
> lopem...@swbell.net wrote:
>
>
> Hi Chris,
>
> AFAIR an image-level GC is just a container and doesn't have any
> associated state in the VM except for one or two WM-level GCs cached by
> the VM. To do a graphics operation the VM inspects the image-level GC's
> inst vars. If they match the cache then the VM will use its cached
> WM-level GC. If not, it'll create a new WM-level GC, initialize it form
> the image-level GC, perform the operation and then cache the WM-level
> GC. So effectively the image-level GC doesn't have any associated
> hidden state, hence you should be able to copy it freely.
>
> --
> The surest sign that intelligent life exists elsewhere in Calvin &
> the universe is that none of it has tried to contact us. Hobbes.
> --
> Eliot ,,,^..^,,, Smalltalk - scene not herd
The variables your referring to must be the one listed in the comment
as "KNOWN TO VM". These include the clipping bounds. That appears to
be where my issue is at. I am trying to simplify it. Right now I
just have it happening in a very simple Simberon Report example. But
it certainly looks like the VM is using the wrong GC on some calls.
As far as I can tell a GC that is created but never actually used to
paint anything (but is copied and used to paint something) is being
used to paint another object even if that other object has a brand new
GC created for painting it.
I am trying to create a simple example outside Simberon.
What is the criteria it uses to determine if a a GC is reused?
Eliot good to see you still involved in VW.
Thanks,
Chris
| |
| lopemanc@swbell.net 2007-07-10, 7:11 pm |
| On Jul 9, 7:23 pm, lopem...@swbell.net wrote:
> On Jul 9, 3:47 pm, Eliot Miranda <eli...@pacbell.net> wrote:
>
>
>
>
>
>
>
>
> The variables your referring to must be the one listed in the comment
> as "KNOWN TO VM". These include the clipping bounds. That appears to
> be where my issue is at. I am trying to simplify it. Right now I
> just have it happening in a very simple Simberon Report example. But
> it certainly looks like the VM is using the wrong GC on some calls.
> As far as I can tell a GC that is created but never actually used to
> paint anything (but is copied and used to paint something) is being
> used to paint another object even if that other object has a brand new
> GC created for painting it.
>
> I am trying to create a simple example outside Simberon.
>
> What is the criteria it uses to determine if a a GC is reused?
>
> Eliot good to see you still involved in VW.
>
> Thanks,
>
> Chris
Here is a simple piece of code that produces the issue. Make sure
your set for Host Printing. Am I screwing something up?
| printer gc newGC |
printer := Printer startPrintJobNamed: 'TmpPrintJob'.
gc := printer graphicsContext.
gc clippingRectangle: (0@0 extent: 50@18).
gc displayLineFrom: 5 @ 0 to: 5 @ 18.
(newGC := gc copy) clippingRectangle: (0@18 extent: 50@50).
BrowserListEntry CFolderIcon displayOn: newGC at: 0@18.
printer print
Assuming you only see the line and not the image like I do, change the
first clipping rectangle to 0@0 extent: 50@25. Now you will probably
see part of the image. As ridiculous as it sounds I think primitive
1233 is not using the right GC. Please tell me if I am doing
something wrong, I would much rather that be the case this time.
Thanks,
Chris
| |
|
| Possible explanation - But I'm just guessing,
with highlights from the info already posted.
See below...
Regards,
-cstb
lopemanc@swbell.net wrote:
> On Jul 9, 7:23 pm, lopem...@swbell.net wrote:
>
> Here is a simple piece of code that produces the issue. Make sure
> your set for Host Printing. Am I screwing something up?
>
> | printer gc newGC |
>
> printer := Printer startPrintJobNamed: 'TmpPrintJob'.
> gc := printer graphicsContext.
so gc is an image-level GC.
> gc clippingRectangle: (0@0 extent: 50@18).
> gc displayLineFrom: 5 @ 0 to: 5 @ 18.
VM checks gc (the image-level GC)
to see if it has a copy in cache.
It doesn't, so it makes a new vm-gc
and copies gc into it, and draws a line on it.
Note that if you changed the clipping rectangle
right now, and drew another line, you'd expect
the vm to use the cached gc, but with the new
clipping rectangle.
> (newGC := gc copy) clippingRectangle: (0@18 extent: 50@50).
We now have
vm-gc = gc
and
newGC = gc
and from
"the image-level GC doesn't have any associated hidden state"
we conclude
vm-gc = newGC
> BrowserListEntry CFolderIcon displayOn: newGC at: 0@18.
VM checks gc (the image-level GC)
to see if it has a match in the cache.
It does have a match, because
(vm-gc = gc and: [gc = newGC].
So it uses the one it already has.
At least, that's how I read Eliot's post.
Cheers,
-cstb
| |
|
|
| lopemanc@swbell.net 2007-07-16, 7:13 pm |
| On Jul 10, 4:21 pm, cstb <j...@cruzio.com> wrote:
> Possible explanation - But I'm just guessing,
> with highlights from the info already posted.
> See below...
>
> Regards,
>
> -cstb
>
>
>
> lopem...@swbell.net wrote:
>
>
>
>
>
>
>
>
>
>
> so gc is an image-level GC.
>
>
> VM checks gc (the image-level GC)
> to see if it has a copy in cache.
> It doesn't, so it makes a new vm-gc
> and copies gc into it, and draws a line on it.
>
> Note that if you changed the clipping rectangle
> right now, and drew another line, you'd expect
> the vm to use the cached gc, but with the new
> clipping rectangle.
>
>
> We now have
>
> vm-gc = gc
> and
> newGC = gc
>
> and from
>
> "the image-level GC doesn't have any associated hidden state"
>
> we conclude
>
> vm-gc = newGC
>
>
> VM checks gc (the image-level GC)
> to see if it has a match in the cache.
> It does have a match, because
> (vm-gc = gc and: [gc = newGC].
> So it uses the one it already has.
>
> At least, that's how I read Eliot's post.
>
> Cheers,
>
> -cstb
This is a bug. Cincom is working on it.
|
|
|
|
|