draw a single point
-
hi, i've searched the graphics-class, but i didn't found how to draw a single point. when i use g.DrawLine(pen,x,y,x+1,y); i get the two pixels connected. when i use g.DrawLine(pen,x,y,x,y); i get nothing. :( any idea? :wq
I would suggest to spit on screen so you would get points on screens :-D More seriously, there is no DrawPoint method available. MS recommends to use GDI (Marshalled) which is still available. Or, if performance is an issue, go unmanaged, lock a ptr on a surface and start playing with it. Now AFAIK, I would recommend a simple to use FillEllipse(x,y,1*nZoomFactor,1*nZoomFactor) where nZoomFactor=1.
And I swallow a small raisin.
-
hi, i've searched the graphics-class, but i didn't found how to draw a single point. when i use g.DrawLine(pen,x,y,x+1,y); i get the two pixels connected. when i use g.DrawLine(pen,x,y,x,y); i get nothing. :( any idea? :wq
SetPixel
"When the only tool you have is a hammer, a sore thumb you will have."
-
I would suggest to spit on screen so you would get points on screens :-D More seriously, there is no DrawPoint method available. MS recommends to use GDI (Marshalled) which is still available. Or, if performance is an issue, go unmanaged, lock a ptr on a surface and start playing with it. Now AFAIK, I would recommend a simple to use FillEllipse(x,y,1*nZoomFactor,1*nZoomFactor) where nZoomFactor=1.
And I swallow a small raisin.
-
SetPixel
"When the only tool you have is a hammer, a sore thumb you will have."
-
:wtf: marshalled? unmanaged? wtf?! i only want to set a single pixel!!! X| it seems, i will try the fillellipse-thing... :| but thx for the tip! :rose: :wq
Here is the code,
// -->declaration
[DllImport("gdi32.dll", CharSet=CharSet.Auto)]
static public extern int SetPixel(IntPtr hdc, int x, int y, int rgb); //// -->usage
// assumption : you have a HDC in hand
// cast your HDC to (IntPtr)
// cast your COLORREF to (int)
SetPixel(dc,x,y,rgb);
And I swallow a small raisin.
-
I would suggest to spit on screen so you would get points on screens :-D More seriously, there is no DrawPoint method available. MS recommends to use GDI (Marshalled) which is still available. Or, if performance is an issue, go unmanaged, lock a ptr on a surface and start playing with it. Now AFAIK, I would recommend a simple to use FillEllipse(x,y,1*nZoomFactor,1*nZoomFactor) where nZoomFactor=1.
And I swallow a small raisin.
-
I would suggest to spit on screen so you would get points on screens :-D More seriously, there is no DrawPoint method available. MS recommends to use GDI (Marshalled) which is still available. Or, if performance is an issue, go unmanaged, lock a ptr on a surface and start playing with it. Now AFAIK, I would recommend a simple to use FillEllipse(x,y,1*nZoomFactor,1*nZoomFactor) where nZoomFactor=1.
And I swallow a small raisin.
-
Here is the code,
// -->declaration
[DllImport("gdi32.dll", CharSet=CharSet.Auto)]
static public extern int SetPixel(IntPtr hdc, int x, int y, int rgb); //// -->usage
// assumption : you have a HDC in hand
// cast your HDC to (IntPtr)
// cast your COLORREF to (int)
SetPixel(dc,x,y,rgb);
And I swallow a small raisin.
-
phew. that works. thx! :rose: anyways - i still don't understand why ms doesn't include a DrawPoint(Pen,int,int) or DrawPoint(Pen,pt) function into the graphics-class. :confused: :wq
I guess for known performance reasons MS didn't think that was a good idea to allow DrawPoint. Well to be honest, the fact that DrawLine(x,y,x,y) does not work properly is a bug. DirectX+GDI advocates have been fighting for years to train developers to lock a ptr to an actual surface, and then poking inside, instead of doing silly SetPixel loops. For real world apps such like real-time imaging, locking surfaces is of course the recommended solution,
And I swallow a small raisin.
-
I guess for known performance reasons MS didn't think that was a good idea to allow DrawPoint. Well to be honest, the fact that DrawLine(x,y,x,y) does not work properly is a bug. DirectX+GDI advocates have been fighting for years to train developers to lock a ptr to an actual surface, and then poking inside, instead of doing silly SetPixel loops. For real world apps such like real-time imaging, locking surfaces is of course the recommended solution,
And I swallow a small raisin.
hmm. might be a reason. when i think it over, i could have created a bitmap before the operation, set the pixels within the bitmap and draw the bitmap at the proper location... i see there's a trade-off between 'amount of code' and 'drawing speed' - but in my simple case the setpixel-speed is abolutely ok. :) :wq