IRC Log Viewer » #firebreath » 2012-03-14

IRC Nick Time (GMT-7) Message
linearray 05:03 taxilian: it's actually not true that ssh access only works when you have write permission on github.
I don't have write permission on firebreath/firebreath and I can clone over ssh just fine
FireBreathBot 06:03 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-171 issue created by wroberts
JIRA issue http://jira.firebreath.org/browse/FIREBREATH-171 issue commented by wroberts "Proposal:
taxilian 09:03 linearray: that's been my experience
that it only works when you have write permission
FireBreathBot 09:03 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-171 issue commented by richard "In general this seems like a reasonable approach; it may make more sense to go ahead and create a..."
linearray 09:03 ok
EvilTengil 10:03 Hello!
FireBreathBot 10:03 EvilTengil: 20 Feb 11:26Z <dougma> tell EvilTengil that's IE 'stripe' painting... this is the code i use to deal with it: http://pastebin.com/nWWg3LQS
EvilTengil 10:03 I'm having more drawing issues
I'm drawing images from memory (kinect video stream) and some text on top of that using GDI
it works good
except on a few computers where it doesnt work when they have disabled aero
It's like if the area isnt really invalidated. Like if the rect wasn't marked as dirty.
taxilian 10:03 odd; GDI shouldn't care, I would think
EvilTengil 10:03 So if something is moved about the plugin window to force a redraw parts of the video is shown for a millisecond. It also works to push the window to a corner when windows 7 shows the snap indication by making the whole window blue.
It's not all computers either, only some. On my laptop it works perfect but i have another laptop next to me where it doesnt work and it doesnt work on a coworkers stationary either
I was actually using the GDI code you posted taxilian
But now I have tried with CreateBitmap and BitBlt and it gives the same result
taxilian 10:03 hmm. I have never seen that issue in my own plugin; of course, I'm using windowless
EvilTengil 10:03 I think this is a issue with dwm since aero affects it
so it makes sense it never happens in windowless
ch 10:03 maybe those non-working computers use non-wddm video drivers?
EvilTengil 10:03 they are fairly new with nvidia graphic cards
so i dont think so
The very strange thing is that underneath the text im also drawing, the image is visible
So it's only that it's not being correctly updated.
I did a test where i first filled the whole area and then drew the image. It flickers a lot but then the image is actually updated on every laptop.
The draw event in FB is called on WM_PAINT right if it's a windowed plugin?
(the virtual function)
taxilian 10:03 yes
try calling InvalidateWindow when you need to draw
EvilTengil 10:03 I'm calling InvalidateWindow on the plugin class (PluginCore) when I get frames from the kinect. It's done from another thread, could that cause any issues?
taxilian 10:03 no, invalidatewindow should be callable from any thread
I think, anyway
pretty sure
EvilTengil 10:03 Is it just calling InvalidateRect or UpdateWindow or something similiar? (Sorry for a lame question I could look up myself but for some reason MSVC crashes when I use to to defintion in FB projects)
taxilian 10:03 !findfile PluginWindowWin.cpp
FireBreathBot 10:03 Found 1 matching file(s) in the master branch. First 1 are:
src/PluginAuto/Win/PluginWindowWin.cpp http://goo.gl/NdqTe
taxilian 10:03 it's in that file
EvilTengil 10:03 sweet :)
in that file, in the WM_PAINT handler. If the SendEvent returns false it calls BeginPaint/EndPaint without drawing anything between and then returns true. But if SendEvent is handled it will just break and the event handler will return false. What does true/false mean here? Is it to stop the DefaultWindowProc?
taxilian 10:03 true means it was handled
false means that the event should be propogated to the next thing that might be handling it
if you don't do the begin/end paint windows will keep sending WM_PAINT until you do
EvilTengil 10:03 ah ok
But if SendEvent returned true, shouldnt the WindProc method return true then as well? I'm guessing that means the plugin handled the draw
taxilian 10:03 hmm. yes, probably it should; I don't know if it actually ends up mattering, but it probably should
EvilTengil 10:03 I'm desperate. I', giving it a try :)
made no difference
taxilian 10:03 if you're drawing using GDI anyway, perhaps you should just make it a windowless plugin
EvilTengil 10:03 I remember I tried doing that before but it didnt work too well
I don't remember exactly what it was but i think there was some issues in some browsers or something
I've had plenty of issues :)
taxilian 10:03 we're using it and it works great for us =]
EvilTengil 10:03 I think the problem was that the drawing became striped in IE
Which on the other hand dougma sent me this link through the chat bot, http://pastebin.com/nWWg3LQS
taxilian 10:03 … right =]
EvilTengil 10:03 Isn't there any performance issues with windowless? Like flash that is much slower with a transparent wmode
taxilian 10:03 there can be; depends on what you're doing
EvilTengil 10:03 I'm drawing a 640x480 10 Hz camera feed with a text on it (Recording/Loading/Error)
taxilian 10:03 10hz? you're probably fine
EvilTengil 10:03 Yeah we limited it to 10 Hz to be able to upload it real time to the server :)
alright I will look into the windowless mode again tomorrow
thanks
ch 11:03 i don't suppose one can do Direct3D drawing with windowless plugins, right?
taxilian 11:03 ch: nope; or at least, you can, but you have to render to an offscreen buffer and then blit it to the screen with GDI