Hi, All -
I''ve been getting closer and closer to a raw painting interface (see
''Inserting
RMagick RVG images in wxRuby'' for my starting point) and now what
I''m
working on (yes, I''m getting paid to work today; my kids are 3000 miles
away
so it''s a welcome distraction) is drawing on a MemoryDC associated with
a
bitmap:
@picture = Bitmap.new( size_x, size_y )
artist = MemoryDC.new
artist.select_object @picture
artist.set_background_mode SOLID
artist.flood_fill( 160, 200, Colour.new( 240, 0, 0, 255 ) )
... and later:
paint_bitmap( @picture, client_size.x, client_size.y )
using the definition (part of my Window sub-class):
def paint_bitmap bitmap, width, height
bitmap = make_dummy if bitmap == nil # dummies for non-existant
images (like cpu1 if single-thread)
rescaled_bitmap = Bitmap.from_image(
bitmap.convert_to_image.rescale( width, height ), -1 )
rescaled_bitmap.save_file( @fname, BITMAP_TYPE_XPM )
paint do | renderer |
renderer.draw_bitmap( rescaled_bitmap, 0, 0, false )
end
@sized = false
end
What appears to be happening is that my bitmaps are not taking over from the
original contents of the memory arrays, because what I see being rendered
appears to be garbage pages from the screen buffer. If I change something in
my GUI (like pressing a button, which changes its color to yellow), I see
smears of yellow showing up in my bitmaps and getting rendered in my GUI.
The Bitmap#draw method referenced in the DC and MemoryDC docs appears to
have gone bye-bye in 2.0, so I''m using the direct instantiation
menthod. I
finally got my copy of Smart and Hock and it says something about
select_object not working if the bitmap is unpopulated, so my next try is to
pull up a base bitmap from a file instead of creating one from new.
Thanks in advance! :D
--
-- Don Wilde
"If you are creative and add value to the world, sleep well.
You''ve earned
it."
_______________________________________________
wxruby-users mailing list
wxruby-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/wxruby-users
On Thu, Nov 25, 2010 at 2:57 PM, Don Wilde <dwilde1 at gmail.com> wrote: [snip]> @picture = Bitmap.new( size_x, size_y ) > artist = MemoryDC.new > artist.select_object @picture > artist.set_background_mode SOLID > artist.flood_fill( 160, 200, Colour.new( 240, 0, 0, 255 ) ) > > ... and later: > > paint_bitmap( @picture, client_size.x, client_size.y ) > > using the definition (part of my Window sub-class): > > def paint_bitmap bitmap, width, height > bitmap = make_dummy if bitmap == nil # dummies for non-existant > images (like cpu1 if single-thread) > rescaled_bitmap = Bitmap.from_image( > bitmap.convert_to_image.rescale( width, height ), -1 ) > rescaled_bitmap.save_file( @fname, BITMAP_TYPE_XPM ) > paint do | renderer | > renderer.draw_bitmap( rescaled_bitmap, 0, 0, false ) > end > @sized = false > end[snip] Bitmap#load_file is also gone, but Bitmap.new has a file option. Never rely on a first-release API to be as documented. ;-) Changing make_dummy to load a file got rid of the uninitialized bitmaps, but I still can''t paint anything on them. The above code should leave me with a screaming red bitmap, but all I get is the white from my blank.png. -- -- Don Wilde ph: 512-394-8896 skype: donwilde1 e: dwilde1 at gmail.com "If you are creative and add value to the world, sleep well. You''ve earned it." -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-users/attachments/20101125/b2d0c018/attachment.html>
On Thu, Nov 25, 2010 at 3:19 PM, Don Wilde <dwilde1 at gmail.com> wrote: [snip]> artist.flood_fill( 160, 200, Colour.new( 240, 0, 0, 255 ) ) >> >> Never mind. I just re-read the flood_fill docs and discovered that theColour in the command is the BOUNDARY color, not the painting color. You can stop laughing now, hope you enjoyed. :D -- -- Don Wilde "If you are creative and add value to the world, sleep well. You''ve earned it." -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-users/attachments/20101125/0245a35e/attachment.html>