I was trying to save a .tga image using GetFrontBufferData method,but alpha value is lost.They are totally one.I could get right alpha value from RenderTarget or BackBuffer,but not rgb value is not correct.Even the scene present to show immediately,backbuffer still seems darker than frontbuffer.
Now I get 2 questions:
Q1:Do FrontBuffer have alpha value?
Q2:What is the difference between the data of back buffer and front buffer when you try to render transparent things?
When you render a transparent object, its alpha value is used to perform alpha blending. Once the blending is completed, new value is written to the back buffer. If you want to preserve the alpha value, the format of the back buffer should be D3DFMT_A8R8G8B8. You should also remember about clearing the alpha channel while calling IDirect3DDevice9::Clear(). Once the rendering is completed, the back buffer and the front buffer pointers are simply flipped (read more). Thus, both buffers have the same format (so if you created the back buffer with RGBA format, the front buffer would also be RGBA). By the way, you can get the back buffer and lock it instead of getting the front buffer.
By default, alpha blending performs the same operations on R, G, B and A channels, but you can specify a separate operation for the alpha channel only - see this.
Related
I am trying to get the color of a pixel on my screen using node.js. I want it to be returned in RGB format, e.g. (255, 0, 0). My current solution is to use screenshot-desktop to screenshot my entire screen in JPG format, decode it to get the raw pixel data, and get the color of a given pixel. However, this lags out my entire computer for 1-2 seconds as it is taking the screenshot. This is unusable as I would like to do this multiple times per second. So my question is: How can I get the color of a given pixel on the screen, without taking a full screenshot?
I am using Linux with X11. There is an X11 library for node.js, so I asssume I should use that to get the pixel color, I'm just not sure how. If you could show me how to do it in C then I can easily use node.js to do the same thing.
Thanks!
Oh my gosh I just figured it out after posting this. I was using robotjs for reading the mouse position and I totally forgot it can do screen stuff too! So, the solution would be to do
var robot = require('robotjs');
var color = robot.getPixelColor(x, y);
X11 solution using x11 node library ( I am the author ):
query windows tree with QueryTree starting at the root window
get every child geometry using GetGeometry request
if your point is not inside any child, use current window id and get 1x1 pixmap from the current image: GetImage(format, currentWindow, x, y, 1, 1, planeMask) ( 2 for format and 0xffffffff for plane mask should work ). Make sure you calculate relative x y position as you travers windows tree.
if child window covers your point query children for that window and repeat again. Note that QueryTree returns windows in bottom to top stacking order so make sure you pick last one covering your point
Once you have 1x1 pixmap from the topmost window under your point - the buffer should contain only color bytes for your image, RGB order and bit mask might depend on red_mask, green_mask, blue_mask from display.screen[0].depths[visual].
If you cache "topmost window" between requests and only start from root when no match anymore the above solution might be much more performant then the one using robotjs ( although much more low level and complicated ) Good luck!
I have an 'old' RGBA canvas on the client and a newer version of the same image on the server. There are small visual differences between them.
I want to be able for the server to send to the client some 'diff' to be able to update it's image to match the new version, without having to send the whole image data again.
A two-frame transparent webm video would be ideal (ie. use webm to encode the differences), but hardware support for webm with transparency is abysmal, and browser support for extracting a specific frame from a video is also very poor.
Instead I am looking at using the hard light blend mode, which should allow me to send a single image to the client, and have any RGBA pixel converted to any other (with a margin of error of 1).
How should I generate the difference image though? Which combination of blend modes can generate diff if new = hardlight(old, diff)
Let Ch, Cw, Cd be the value you have, the value you want, and the diff value:
if (Cw > Ch)
Cd = 1 - (1-Cw)/2(1-Ch)
else if (Cw < Ch)
Cd = Cw/2Ch
else
Cd = 0.5
There are three basic ways to move a path in Raphael.
If that path has a fill image that has PNG transparency, and you need IE8 (VML), all three are flawed.
JSBin demo
If you use a simple transform...
path1.animate({transform: 't20,100'},1000);
...then in IE8, the png transparency in the fill breaks and translucent pixels turn black. Edges become pixelated and ugly, and depending on the image you might get a scuffy black outline around the translucent edge of the image. Not good, and there doesn't seem to be any reliable way to fix this after the event.
Sometimes, inconsistently, the background image also doesn't stay relative to the element (more on that below).
If you animate the path attribute, for example like this:
path2.animate({path: Raphael.transformPath( path2.attr('path'), 't100,20') },1000);
...IE8 doesn't wreck the image background. However, the fix for making background images relative to the element not the paper does not work with this method (and various ways I've tried to bodge it using improved background image offset with an additional "M-20,-20" element don't seem to work), and I can't find any way to make that work either.
Also, just having lots of transformations on the go can break the delicate IE8 bug the background image fix depends on in VML mode, causing the background to move. This seems to be inconsistent - with the JSBin above, in IE8, sometimes they all move, sometimes only the top one moves.
If you use translate...
path3.translate(42,42);
...the results are the same as transform (presumably both use the same translate functions).
With Raphael image elements, it's possible to fix this broken alpha by applying opacity with the transform in an attr or animate call. This doesn't work with path fills. Also, turning off the fill and resetting it from the original URL string doesn't remove the broken alpha contamination. You can see this in this demo.
So, I'm looking for a way to move a Raphael path that has a background image that has PNG transparency that a) keeps the image relative to the element, consistently and b) doesn't wreck the PNG transparency in IE8 by turning partial transparency into pixelated black.
Similar problems occur with any form of transformation - such as scale, rotate etc.
I can't find any good answer to this: the closest I've found is an ugly but functional workaround for IE8 transform (wrapped in if(Raphael.type=='VML')s so you don't spoil things for real browsers):
Before doing any transform to anything that has an alpha transparency PNG / pattern fill, remove the pattern fill (path.attr({fill:'none'});), storing the fill setting like path.data('fill',path.attr('fill'));
After the transform, asynchronously (e.g. wrapped in setTimeout(function(){ })) re-apply the fill e.g. path.attr({fill: path.data('fill')});
The crucial thing seems to be: the fill must not be applied when the transform occurs, else it'll be ruined forever, even if you remove and re-apply it. Be careful with the timing on this - it mustn't be possible for the fill to re-apply before the transform completes (e.g. watch out for race conditions with animations or other async processes).
If you're animating a transform, your options seem to be to either:
Clear the fill before the animation, just accept that there will be no fill while the animation takes place, and re-set in a callback after the animation completes
Implement your own animation handler than removes and re-applies the fill before and after every frame (this, of course, risks being a performance nightmare).
Is it possible to move part of the texture into another texture part without performance hits?
I looked into opengl SDK, but haven't found anything that could do something like this.
glCopyPixels lets you to copy from one framebuffer area into another (I never used it).
glBlitFramebuffer lets you to copy pixels between framebuffers
glCopyTexImage lets you to copy pixels from framebuffer into a texture
Using these function you can accomplish the task by, for example, the following actions:
create FBO, attach texture-1 into the first color channel
bind fbo, set viewport to contain the source area
call glCopyTexSubImage into the texture-2 to get the contents
I've been stumbling over this for a while and was wondering if anyone has run into this problem before.
The application I'm working on is divided into multiple data plots and a single timeline at the bottom of the screen. Each plot (which is actually multiple textures layered on top of each other) as well as the timeline is rendered to a separate texture. The timeline texture is rendered first, followed by each of the plot textures from the top of the screen to the bottom. I am using DXUT and DirectX9 (March 2009).
After adding time text to the timeline texture, I noticed that the text was repeated in the title bar of every data plot. Here's a screencap of a portion of the display, it shows just a single plot, but the text repeats on every plot opened:
It seems like it is tied directly to the DrawText being called in the timeline's render function. I do use relative coordinates as the rect being passed to DrawText, but since I've already set the render target to the desired texture it should only affect the current texture. Not every texture rendered afterward.
Has anyone ever run into any problems similar to this using D3DXFont?
EDIT: After some more experimentation, it looks like it has something to do with the Z buffer. By adding D3DCLEAR_ZBUFFER to the clear on each texture surface, the duplicate text is gone. While the problem seems bypassed for now, I'm still curious as to why the Z buffer for a completely separate texture was being written during my DrawText call.
The Z Buffer state is persistent.
For example,
SetDepthStencilSurface(X)
SetRenderTarget(A)
Draw()
SetRenderTarget(B)
Draw()
Both Draw calls will use the same depth buffer.
The DrawText is not changing the depth buffer that you have set. It assumes you meant to do what you did.