I was trying to display something on screen using UEFI.
Almost PC which had UEFI drawed well with framebuffer.
But one PC had older UEFI and I had to draw using Blt function in EFI_GRAPHICS_OUTPUT_PROTOCOL.(Probably because that PC's IGP had no UEFI module..)
But whenever I try it, it doesn't do anything.
I tried same thing in VMware, but it doesn't work either.
This is what I have tried.
EFI_GRAPHICS_OUTPUT_BLT_PIXEL p;
p.Red = 255;
p.Green = 0;
p.Blue = 0;
EFI_STATUS status = prot->Blt(prot, &p, EfiBltVideoFill, 0, 0, 0, 0, width, height, 0);
NOTE: prot is instance of EFI_GRAPHICS_OUTPUT_PROTOCOL.
I googled and I couldn't find any problem with arguments and I checked status variable and it said EFI_SUCCESS.
That thing draws red pixel to entire screen, right?
But it didn't draw anything on screen.
I tried this after drawing something on framebuffer.(And of course, it worked pretty well on VMware)
But I couldn't see any change on screen. Not even a black screen or something else. What I could see is what I had draw using framebuffer.
Am I doing something wrong?
Of course, I haven't used ExitBootServices() yet.
Try getting all protocol handles, not just one, because some systems have multiple instances of GOP, and the first one can be a black screen (second monitor which is not connected now, etc.) you are trying to write to.
Related
As shown by the attachment, i'm presenting multiple images on a computer monitor. I can physically view the very first one that is presented, but on the next trial, the texture's I've drawn are done correctly, but they do not appear on the display itself. I know they are done correctly because I used Screen('GetImage') to obtain the copy that you see attached here. So i'm not sure what i'm doing wrong. I'm used to using offscreenwindow's, but here i opted to draw textures on the onscreen window. This is a psychtoolbox problem.
I'm using this code to upload the image, make a texture out of it, and draw it to the onscreen window
img = imread(trial(t).nontargetImage); img = imresize(img, picResize); [iy, ix, ~] = size(img);
txtIndex=Screen('MakeTexture', expWin, img);
Screen('DrawTexture', expWin, txtIndex, [],...
[loc(i).x-(ix/2), loc(i).y-(iy/2), loc(i).x+(ix/2), loc(i).y+(iy/2),]);
and on trial 1, i'm seeing that the below appears correctly with the following code
[startRT] = Screen('flip',expWin);
But when trial 2 comes, and the expWin gets drawn to again with different textures, the expWin, when flipped, does not show anything at all (or at least i cannot see it). All i see is a black screen.
I was using Windows 7, which was the issue. When I updated the computer to windows 10, it worked!
I'm trying to create a hotkey that will find the google sheets "tools" menu, click on it, move down a few pixels and click on script editor. I could do this within google sheets but it doesn't have universal keybinds for this, I'd have to make a macro and I'd rather it just be universal.
SC163::
{
ImageSearch, FoundX, FoundY, 0, 0, A_ScreenWidth, A_ScreenHeight, C:\Users\xx\Documents\AHK Scripts\gsheets-tools.bmp
if ErrorLevel = 2
tooltip Could not conduct the search.
else if ErrorLevel = 1
tooltip Image could not be found on the screen.
else
{
mousemove, %FoundX%, %FoundY%, 50
tooltip The image was found at %FoundX%x%FoundY%.
}
return
}
It was throwing error 2 until I hardcoded the entire image name. Now it only throws error 1, even if I have three copies of sheets open (one on each monitor). Is BMP not the best format to use here? I tried using
ImageSearch, FoundX, FoundY, 0, 0, A_ScreenWidth, A_ScreenHeight, *n30 C:\Users\xx\Documents\AHK Scripts\gsheets-tools.bmp
to see if adding that allowance would helps, but failure. Any tips for using image search correctly? This isn't some sophisticated game function, just trying to find a toolbar and click on it!
Try changing *n30 to just *30.
Also, by default, ImageSearch coordinates are per the active window and not the entire desktop, so using A_ScreenWidth and A_SreeenHeight might be problematic. While this isn't an issue if the window is maximized on your primary screen, it may present a problem if it's not maximized or is on a screen with a different resolution. If it's not maximized, it could be searching an area that goes beyond your display area, which might be an issue.
Possibly another issue (unverified) could be with Windows scaling. A lot of times a 2160p monitor defaults to 200% scaling (or is it 150%? w/e).
Since you're using BMP images, you may want to verify that it was saved as 16-bit or higher.
Notable quotes from the help file:
All operating systems support GIF, JPG, BMP, ICO, CUR, and ANI images (BMP images must be 16-bit or higher).
. . .
The region to be searched must be visible; in other words, it is not possible to search a region of a window hidden behind another window. By contrast, images that lie partially beneath the mouse cursor can usually be detected. The exception to this is game cursors, which in most cases will obstruct any images beneath them.
I suggest you using this for Image Search
https://www.youtube.com/watch?v=aWRAtvJq9ZE
It is very simple and works pretty good!
When I create a figure with MATLAB with a title, then use the File|Print option to print the figure, the title is clipped. Please try this code for an example
t = linspace(0,2*pi,1000);
s = sin(t);
figure
plot(t,s)
titleString = sprintf('Multi\nLine\nTitle');
title(titleString)
disp('Now press File|Print Preview on the figure and observe that the title is clipped.')
disp('This happens with all titles, the multi line title makes it more obvious.')
disp('I know I can fix it with Fill Page or Center, but I should not have too.')
You can also see the problem in print preview. As I say in the example code, I know I can get round the problem using Print Preview then Fill Page or Center, but I don't want people using my code to have to use a work around.
I have observed this problem with r2014a and r2015b. I assume other releasse are also affected.
Is there setting I can make before creating the figure that centres the plot or fills the page and makes the problem go away? Is there some other setting I should make to avoid the problem?
Here is a little more debug information. If I press File|Print Preview, MATLAB reports Left 0.64, Top -0.59, Width 20.32, Height 15.24. I guess the problem is related to the negative Top value. These are defaults from MATLAB; I have not made any attempt to change these values.
One extra thing. I am in the UK, so my default paper/printer setting will be for A4 paper, if that makes a difference.
Edit:
It looks like my problems are caused by two lines further up in my program:
set(0,'DefaultFigurePaperOrientation','landscape')
set(0,'DefaultFigurePaperType','A4')
I think that becuase plots expect to be on paper with a portrait orientation, I am seeing these problems.
Perhaps I should revise my question to: what to I need to change in MATLAB figures so they print correctly on landscape A4 paper (ideally in the center, scaled to fill the page, but with correct orientation). All this without using Print Preview.
But I am going to do this instead to code around my problem.
set(0,'DefaultFigurePaperOrientation','portrait')
set(0,'DefaultFigurePaperType','A4')
I can't seem to reproduce your problem on the computer I'm currently on (see the values I'm getting by default - Top is 8.11):
However, if your problem is what I think it is (I'm getting something that fits this description on another computer I'm working on), try adding _{ } at the end of your string. This is a TeX string meaning "subscripted space" which pushes the rest of the text slightly upward. You can also use ^{ } on the first line if the clipping is happening from the top. I found this workaround to work on axis titles and labels as well.
Exaggerated, the workaround looks like this:
titleString = sprintf('^{^{^{^{^{^{ }}}}}}Multi\nLine\nTitle');
Which shows the word "Multi" even for Top = -0.59.
If the above is not what you're looking for, you might want to look at the robust export_fig.
I can confirm that my clipping problems are caused by this line:
set(0,'DefaultFigurePaperOrientation','landscape')
I have revised my program to start with this instead.
set(0,'DefaultFigurePaperOrientation','portrait')
set(0,'DefaultFigurePaperType','A4')
And the problem has gone away.
Users can still print in landscape if they use the print preview feature.
To try and solve this problem, I started looking into writing a plugin for flot to do what I needed. It looked surprisingly straight-forward, but I have run into a minor snag. I First used the draw hook to draw my axis (note: I'm aware this code needs some error checking to make sure the origin isn't off the chart)
function draw(plot, ctx) {
var offset = plot.getPlotOffset();
var origin = plot.pointOffset({ x: 0, y: 0 });
ctx.moveTo(offset.left, origin.top);
ctx.lineTo(plot.width() + offset.left, origin.top);
ctx.stroke();
ctx.moveTo(origin.left, offset.top);
ctx.lineTo(origin.left, plot.height() + offset.top);
ctx.stroke();
}
And this works, with 2 small snags. The first and most important is that for some reason it makes the very last point of my data series change color! See here:
The point in the upper right-hand corner has turned black. By stepping through the code I can observe that this only happens when the axes are drawn. Before my draw code is called, the point is the correct color. So I think it has something to do with the drawing on the first "stroke". For some reason it seems to then apply the black color to the last point. Any idea on how to fix this?
The second problem is that this code is called only after flot has draw everything else (including the data points) which means that my lines appear on top of points instead of underneath them. This is only a problem for those two points that are very close to the vertical axis. Looking at the flot documentation, it mentions a drawBackground hook, but this doesn't seem to actually exist. I tried using it and it complained the drawBackground was null. So what happened? And is there a better place to hook into and draw my axes? I want to draw after flot has worked out the size of the plot area and before it draws the first series of data points.
What's currently on the website API documentation does not match the newest released version (0.7). In order to use the backgroundDraw hook, you'll need a newer version of flot, directly from their github repository. The newest version is fine, but anything after this commit would be workable.
I have a question about the values returned by getPosition. Below is my code. It lets the user set 10 points on a given image:
figure ,imshow(im);
colorArray=['y','m','c','r','g','b','w','k','y','m','c'];
pointArray = cell(1,10);
% Construct boundary constraint function
fcn = makeConstrainToRectFcn('impoint',get(gca,'XLim'),get(gca,'YLim'));
for i = 1:10
p = impoint(gca);
% Enforce boundary constraint function using setPositionConstraintFcn
setPositionConstraintFcn(p,fcn);
setColor(p,colorArray(1,i));
pointArray{i}=p;
getPosition(p)
end
When I start to set points on the image I get results like [675.000 538.000], which means that the x part of the coordinate is 675 and the y part is 538, right? This is what the MATLAB documentation says, but since the image is 576*120 (as displayed in the window) this is not logical.
It seemed to me like, somehow, getPosition returns the y coordinate first. I need some clarification on this.
Thanks for help
I just tried running your code in MATLAB 7.8.0 (R2009a) and had no problems with image sizes of either 576-by-120 or 120-by-576 (I was unsure which orientation you were using). If I left click inside the image, it places a new movable point. It did not allow me to place any points outside the image.
One small bug I found was that if you left-click in the image, then drag the mouse pointer outside the image while still holding the left button down, it will place the movable point outside the image and won't display it, displaying a set of coordinates that are not clipped to the axes rectangle.
I'm not sure of what could be your problem. Perhaps it's a bug with whatever MATLAB version you are using. I would suggest either restarting MATLAB, or clearing all variables from the workspace (except for the image data im).
Might be worth checking to see which renderer you are using (Painter or OpenGL), a colleague showed me some wierd behaviour with point picking when using the OpenGL renderer which went away when using the Painter renderer.
Your code uses the Image Processing Toolbox, which I don't have, so this is speculation. The coordinate system is probably set to the figure window (or maybe even the screen), not the image.
To test this, try clicking points outside the image to see if you can find the origin.