Replacement for graphics.pixel methode

What exactly is the replacement for the pixel methode of the Graphics class. Is there any?
If I want to perform individual pixel manipulations in Graphics objects, how can that be done? I have some legacy code like this:

DrawHandlePoint(g As Graphics, x As Integer, y As Integer)
g.Pixel(x,y) = &c333333
g.Pixel(x+1,y+1) = &cFFFFFF
End Sub

The Graphics-object processed in the above code is provided bei a paint-Event. I can’t see any chance of converting g into a Picture-object or rather is it much too complicated. Shouldn’t the graphics-class also be provided with a RGBSurface-property? I consider the lack of the RGBSurface property in the Graphics class to be a defect.

Kind regards and many thanks in advance for your efforts.
Roger Kaufmann

But then you are in a vector-based world, where there are no pixels.
You could create a picture and draw that into.

You’ve got that backward. At the beginning Paint, you create a picture the same size as g. You do all your drawing to the picture. At the end of the paint event, you draw the picture to g.

what you paint in canvas paint event is temporary.
if a other windows move over this canvas it get invalid and the paint event raised again.

for a permanent picture you can sublass your canvas and add a picture property there.
in the paint event you can use g.drawpicture

  1. Canvas
    mini paint

First of all, many thanks to everyone who has taken the trouble to answer me.
In reality, I can’t quite understand why such an RGB surface property is not allowed in there (graphics-class). We are talking about UI drawing here and that is pixel-oriented, isn’t it? I hope that some of those responsible for Xojo will read this and change their minds…

Tim told you to use a Picture and do your graphics related manipulations there.

You can use RGBSurface in relation to that Picture. Look at the Documentation for more details…

I’m with you.

But in this case, I would ignore the advice about ‘create a picture of the same size’ etc etc
The main use for the rgbsurface is speed: the pixel method is much faster on rgbsurface than on graphics.
However, if you are only drawing a couple of dots, any speed increase from rgbsurface is wasted by the time taken to make a picture, draw on the picture, the draw the picture to the graphics that was passed into the paint event.

The speed consideration has to take account of the complexity of the drawing… at some point , keeping a pre-drawn picture on hand may make sense.

edit: even calling DrawHandlePoint carries an overhead.

If I may say so - I think you have a foundational misunderstanding of how the Graphics object works.

The Graphics object is an assembly of functionality that lets you draw. It sits “in front of” several different output contexts: bitmap Picture objects, vector Picture objects, PDF contexts, printer output contexts, screen contexts in the Paint event, etc. You can’t ever have a Graphics object in the absence of an output context.

The idea is to let you write your drawing code once and repurpose it into a different context. That’s why the Graphics object doesn’t have a Pixel operator: several of the contexts behind the Graphics object don’t know anything about Pixels.

The good news is that you can reach “behind” the Graphics object and access the pixels directly if you are using an appropriate context. For example:

Dim p as Picture

p=new Picture(200, 200)

Dim g as Graphics

g.DrawLine(0, 0, 100, 100)

Dim r as RBGSurface

r=p. RBGSurface

r.Pixel(20, 60)=RGB(12, 34, 56)

This lets you use Graphics functionality and access pixels at the same time. Once your drawing is complete, you can take the resulting Picture and draw it wherever you wish.