I posted this in ruby-talk a moment ago accidentally, so I''m sorry if
you
see it twice. It''s kind of late at night and I''ve been
boggling at this
problem for a while, so my brain doesn''t seem to be working right.
Here are the contents of my original ruby-talk incursion:
Hi,
I''m trying to combine FXRuby with RMagick. I''ve searched the
mail archives
(I had to index them myself! Is there an easy to use official search page
somewhere?) and apparently it''s been done before, but I can''t
seem to get it
to work.
Basically I''m processing my image and then doing an export_pixels and
trying
to convert it to the FXImage format. It works the first time, but when I try
to do it again it crashes on my saying ''invalid image'' in
Linux, or
something useless about abnormal termination in Windows.
This is the piece of code that seems to be giving me the specific trouble:
pixels = []
@current_image.export_pixels(0, 0, @current_image.columns,
@current_image.rows,
"RGBA").each_slice(4) { |rgba| pixels << FXRGBA( *rgba ) }
an_image = FXImage.new(app, pixels, IMAGE_OWNED|IMAGE_KEEP,
@current_image.columns, @current_image.rows )
That works the first time - I get a nice picture as expected when drawn to
the canvas. The next time it happens via a timeout, I get the crash.
Actually, it''s more like it works fine if I do it before calling
app.create(or maybe run?), but not afterwards.
I''ve also tried the following as mentioned in one of the messages in
the
archives, but it complains that it''s looking for an Array (buffer is
FXMemoryBuffer class of course):
buffer = FXMemoryBuffer.new( pixels )
an_image = FXImage.new(app, buffer, IMAGE_OWNED|IMAGE_KEEP,
@current_image.columns, @current_image.rows )
I''ve tried several different combinations of the flags, and putting
an_image.create in various places. The former didn''t help at all, but
in the
latter I just got a black image.
Am I doing something idiotic somewhere? I''m kind of new to ruby and GUI
development in general being more of web app guy. I can post a runnable
version of the code up somewhere if the problem isn''t completely
obvious and
of course if someone is feeling charitable enough to take a look at it.
Thanks for your help!
-Pawel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/fxruby-users/attachments/20051019/5eb736a7/attachment-0001.htm
On Wednesday 19 October 2005 02:21 am, Pawel Szymczykowski wrote:> I posted this in ruby-talk a moment ago accidentally, so I''m sorry if you > see it twice. It''s kind of late at night and I''ve been boggling at this > problem for a while, so my brain doesn''t seem to be working right. > > Here are the contents of my original ruby-talk incursion: > > Hi, > > I''m trying to combine FXRuby with RMagick. I''ve searched the mail archives > (I had to index them myself! Is there an easy to use official search page > somewhere?) and apparently it''s been done before, but I can''t seem to get it > to work. > > Basically I''m processing my image and then doing an export_pixels and trying > to convert it to the FXImage format. It works the first time, but when I try > to do it again it crashes on my saying ''invalid image'' in Linux, or > something useless about abnormal termination in Windows. > > This is the piece of code that seems to be giving me the specific trouble: > > pixels = [] > @current_image.export_pixels(0, 0, @current_image.columns, > @current_image.rows, > "RGBA").each_slice(4) { |rgba| pixels << FXRGBA( *rgba ) } > an_image = FXImage.new(app, pixels, IMAGE_OWNED|IMAGE_KEEP, > @current_image.columns, @current_image.rows ) > > That works the first time - I get a nice picture as expected when drawn to > the canvas. The next time it happens via a timeout, I get the crash. > Actually, it''s more like it works fine if I do it before calling > app.create(or maybe run?), but not afterwards.What happens is, during create(), FXImage transfers the pixel data from the client [your application] to the X11 Server. The image->create() is broken up into 3 steps: 1) create the X11-Server resident pixmap. 2) transfer the pixel data from the FXImage into this map, using the render() function. 3) if IMAGE_KEEP is not specified, release the client-side pixel data since they''re no longer needed.>From this, you can surmise that it is indeed possible to change the pixmapkept in the X11 Server later on:- just call render() again. Of course, IMAGE_KEEP is needed to ensure that the client-side pixel data is still around as well.> I''ve also tried the following as mentioned in one of the messages in the > archives, but it complains that it''s looking for an Array (buffer is > FXMemoryBuffer class of course): > > buffer = FXMemoryBuffer.new( pixels ) > an_image = FXImage.new(app, buffer, IMAGE_OWNED|IMAGE_KEEP, > @current_image.columns, @current_image.rows ) > > I''ve tried several different combinations of the flags, and putting > an_image.create in various places. The former didn''t help at all, but in the > latter I just got a black image. > > Am I doing something idiotic somewhere? I''m kind of new to ruby and GUI > development in general being more of web app guy. I can post a runnable > version of the code up somewhere if the problem isn''t completely obvious and > of course if someone is feeling charitable enough to take a look at it.I''m assuming you''re talking about FXMemoryStream? Anyway, FXStream is useful as it allows e.g. FXBMPImage to extract a BMP-type image from a sequence of bytes. This uses the bmpimage->loadPixels() API. More typically this is used in conjunction with FXFileStream (in C++): FXFileStream strm; if(strm.open("filename.bmp",FXStreamLoad)){ FXBMPImage *bmp=new FXBMPImage(app,IMAGE_KEEP|IMAGE_SHMI|IMAGE_SHMP); bmp->loadPixels(strm); strm.close(); } Hope this helps, Jeroen
> From this, you can surmise that it is indeed possible to change the pixmap > kept in the X11 Server later on:- just call render() again. Of course, > IMAGE_KEEP is needed to ensure that the client-side pixel data is still > around as well.Hi Jeroen, Thanks for the response! It looks like I was confusing the issue a bit in my original testing by switching from an FXImageView to an FXCanvas which I don''t really understand that well especially when drawing contexts come into place. When I went back to the FXImageView, just calling .create on the image before returning it seemed to fix my problem, however I''m not sure what I''m doing (reassigning @imageview.image = [a new image object] every second) is the most efficient way. I tried manipulating the pixel buffer directly as you suggest - would I have to do it with setpixel? I guess I can''t access the .data attribute writer directly. Is there a better way I can update an imported image periodically? I''m working on a sort of primitive motion detector for a video stream with visual feedback - Ideally I''d like to be able to get something like 5 to 15 frames per second, but the way I''m doing it right now might be a bit too slow for that. I''m assuming you''re talking about FXMemoryStream? Anyway, FXStream is useful> as it allows e.g. FXBMPImage to extract a BMP-type image from a sequence > of > bytes. This uses the bmpimage->loadPixels() API. More typically this is > used in conjunction with FXFileStream (in C++):Actually, I guess I was thinking about FXMemoryBuffer as referenced in the docs for the pixel buffer of FXImage: data [R] Pixel data [FXMemoryBuffer<http://www.fxruby.org/doc/api/classes/Fox/FXMemoryBuffer.html> ] But I turned out to be confusing it with the array of FXColor pixels values passed to FXImage.new. Basically I''ve been very confused about the way the whole thing works Hope this helps,>It has indeed - I wasn''t clear on what FXImage.create was actually doing before, so I overlooked my larger overall problem with the Canvas object. Thanks! -Pawel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/fxruby-users/attachments/20051019/46ad6e80/attachment.htm
On Wednesday 19 October 2005 18:08, Pawel Szymczykowski wrote:> > From this, you can surmise that it is indeed possible to change the pixmap > > kept in the X11 Server later on:- just call render() again. Of course, > > IMAGE_KEEP is needed to ensure that the client-side pixel data is still > > around as well. > > Hi Jeroen, > > Thanks for the response! It looks like I was confusing the issue a bit in my > original testing by switching from an FXImageView to an FXCanvas which I > don''t really understand that well especially when drawing contexts come into > place. When I went back to the FXImageView, just calling .create on the > image before returning it seemed to fix my problem, however I''m not sure > what I''m doing (reassigning @imageview.image = [a new image object] every > second) is the most efficient way. I tried manipulating the pixel buffer > directly as you suggest - would I have to do it with setpixel? I guess I > can''t access the .data attribute writer directly. > > Is there a better way I can update an imported image periodically? I''mFor motion video, FXImage is probably not ideal; there is no FOX widget for this, but something like an XV [X video extension] would probably be better. With suitable hardware support, it should be able to do 30frames/second at full video resolution. - Jeroen -- +----------------------------------------------------------------------------+ | Copyright (C) 23:30 10/19/2005 Jeroen van der Zijp. All Rights Reserved. | +----------------------------------------------------------------------------+
Hi everyone here I''m with a small question on FXToolBar that I hope is not another faq one (I''ve tried to search around, but with not so much effort I have to admit) .. I''m migrating my application to FXRuby 1.2 to the new 1.4 and wow, I''m so happy till now .. the only problem I''ve found is the following one that maybe depend on my wrong usage of the new toolbar classes .. in the previous version I remember that when a window was resized in such a way that the buttons in a toolbar were too many to fit the window width, they were automatically moved in more than one row .. now it seems I am not able to reproduce that behaviour .. when I resize my window and the toolbar is larger than the window width, the most right buttons just disappear outside the window frame .. is this a new intended behaviour? Or maybe I''m doing something wrong? Thanks so much for the help, Riccardo :) -- Riccardo Giannitrapani I.N.F.N - Sezione di Trieste and Dipartimento di Fisica Universita` di Udine - Via delle Scienze, 206 Udine (Italy) Room L1-14-BE Tel (Office): +39-0432-558209 Home Page: http://www.fisica.uniud.it/~riccardo ICQ# 86590904 ---- There are only 10 kinds of people in this world: those who understand binary and those who don''t. (Anonymous)
On Thursday 27 October 2005 16:02, Riccardo Giannitrapani wrote:> Hi everyone > > here I''m with a small question on FXToolBar that I hope is not another faq > one (I''ve tried to search around, but with not so much effort I have to > admit) .. I''m migrating my application to FXRuby 1.2 to the new 1.4 and > wow, I''m so happy till now .. the only problem I''ve found is the following > one that maybe depend on my wrong usage of the new toolbar classes .. in > the previous version I remember that when a window was resized in such a > way that the buttons in a toolbar were too many to fit the window width, > they were automatically moved in more than one row .. now it seems I am > not able to reproduce that behaviour .. when I resize my window and the > toolbar is larger than the window width, the most right buttons just > disappear outside the window frame .. is this a new intended behaviour? Or > maybe I''m doing something wrong? > > Thanks so much for the help, Riccardo :)Since 1.4, there is a new toolbar docking algorithm. The toolbars are no longer directly children of FXTopWindow, but of a FXDockSite which is itself a direct child of FXTopWindow. The upshot of this new arrangement is that the wrapping algorithm [which needs a known width or height], is now done in FXDockSite rather than FXToolBar. In other words, the icons in the toolbar don''t wrap, but if you have a bunch of toolbars side by side, they would wrap based on the FXDockSite''s dimensions. My advice is to use smaller toolbars; you can park them side by side at first, but if the window is made smaller they''ll wrap and occupy two lines in the dock site. I''m not convinced yet that the wrapping behaviour as we used to have it in FXToolBar is impossible, but it has become a non-trivial due to coupling between side-by-side toolbars. - Jeroen -- +----------------------------------------------------------------------------+ | Copyright (C) 23:00 10/27/2005 Jeroen van der Zijp. All Rights Reserved. | +----------------------------------------------------------------------------+