I have built Skia. What do I do now to get an SkCanvas and draw on it? This answer does not properly answer the question because
A: It uses API that doesn't exist anymore, like bitmap.lockPixels(),
B: It uses some unkown context and draws a this from it,
C: It doesn't actually create an SkCanvas?...
Ideally I would like an example that doesn't assume anything. A full C++ program that draws something on the screen using Skia.
Follow this detailed procedure (for Linux too!).
If you have problems doing that, in the comments I have proposed solutions for problems I have encountered.
Related
I'm looking for a way to get the actual available screen space, similar to the Cocoa NSScreen visibleFrame method, but on Linux. That would be the displays resolution minus the menu-bar/dock/title-bar.
I'm using SDL2 for the windowing code, but can't find anything within the library documentation that might help.
SDL_GetWindowMaximumSize seems like the closes candidate, but this is returning 0,0 for me.
Any ideas?
Use SDL_GetDesktopDisplayMode(),( previously SDL_GetVideoInfo() in
SDL1.2)
https://wiki.libsdl.org/SDL_GetDesktopDisplayMode
Question Intro
I'm running an opencv project in Visual Studios 2010 and have implemented cuda support (refer to my previous question for precise info on my set-up). All cuda-functionalities are working fine - to the best of my knowledge - and are indeed improving speed on the image processing.
However, I now also wanted to attemp to speed up the video-writing function in this project by replacing the current cv::VideoWriter with the gpu::VideoWriter_GPU function. The reason for this is that the cv::VideoWriter seems to somehow cause processes running outside of the scope in which the VideoWriter is called to be slowed down, resulting in images available at the DirectShow driver being dropped by the VideoCapture-function, hence messing up an algorithm I've implemented.
Problem
To attempt to solve this issue, I've now replaced the VideoWriter-calls with VideoWriter_GPU-functionality (and corresponding syntax), but when I run my project (Compile & Run in Debug-mode), I get the following error-message (directly originating atthe calling of gpu::VideoWriter_GPU):
OpenCv Error: The function/feature is not implemented (The called functionality
is disabled for current build or platform) in unknown function, file
c:slave\builds\wininstallermegapack\opencv\modules\gpu\src\precomp.hpp, line 131.
and the program then ends with
code -529697949 (0xe06d7363)
I've purposely currently not included any of my code because the error-message originates so clearly from the call to the gpu::VideoWriter_GPU, which is making me think it's not a coding or syntax problem. (Please comment if you feel my code is necessary for answering this question.
My steps so far
I miss the natural gift of understanding what precisely this message means or how to interpret it. Does my opencv v2.4.4 simply not support what I want...? Does this function simply not work on my windows 7, 64bit system...?
I've checked out as many available google-hits I could find (relating to this error message and combinations of searchterms like "opencv, gpu, VideoWriter_GPU, disabled for current build") but have not understood what the problem is or how to solve it.
Corresponding header-file and error message can also be found here.
This post and this post suggest the error message is trying to tell me that opencv simply does not provide the option of using the function or functionality I am aiming to use. Or maybe even that cuda is not at all supported.. But that's all against my experience as every single opencv gpu-function I've tried to use has seemed to work fine.
Question
Could someone please explain to me why this is not working for me, and more importantly share with me what I should do to make the VideoWriter_GPU work?
Many thanks!
Maybe this link can give you a little idea of what the problem is: VideoReader_GPU not available, but built with NVCUVID?.
It seems to be that the problem is the CUDA_DISABLER var.
I've written a program based on an empty Win32 console app in VS2008 running on Win7 64bit. The program is entirely menu based spawning from a main.cpp which only calls external functions that lead to other interfaces based on the users needs (e.g. cashier, inventory, report, etc...). What I would love to do is provide a new console window for each interface.
Ideally it would close the main menu upon invoking any other interfaces and so on as the user progresses through its functions, including reopening the main menu when necessary.
The basis for doing it this way is that I'm starting a new semester next week diving deeper in OOP with C++ and I wanted to go over my text and complete the capstone project which progresses with the topics to ensure that I have all the basics down pat. As much as I would love to do this the smartest-easiest way, it's best if I stick to the limited knowledge presented in the book which only hints at STL and speaks nothing of additional libraries like boost.
I, of course, have searched on SO and elsewhere looking for the solution. I have found answers, most of them falling outside of my tight requirements, some dealing with building a console window from scratch. While from-scratch seems the most promising, it seemed to be dealing with those not using a robust IDE like VS and I don't know if it will cause more conflict than it's worth, or if it can even be used in multiplicity. The majority, however, left me with the impression it isn't possible. The one exception to this was linking a console to a process. This is what I hope is in my future!
What brought me to this was the need to present a clean look at each turn of events. At first I was fooling around with trying to clear the screen with a basic function like void clearScreen(int lines); but this will always clear from the bottom. So, if I clear the screen before the next interface it's still at the bottom. If I clear it then accept input, the prompt is still at the bottom.
In case it hasn't been clear up to this point. My question is:
Is it possible, within reason, to produce multiple console windows which are tied to processes, or is there an easy way which I do not know to manipulate the scrolling of the main console window?
Even though I "need" to stay within the confines of the baby-step process of traditional learning, I would love to hear any input aside from switching the app type.
This is more of an OCD issue than a requirement of the task, so if the effort isn't worth the benefit that's okay too.
There is no portable way of moving the cursor around the console window - in Unix/Linux, you can send terminal codes for that, in Windows I have no idea.
What would work cross-platform, but be terribly slow and not too nice, would be:
read your input character-by-character
remember where on the screen the next character should appear
redraw the whole screen after each key press
If you want to do better, you must turn to platform-specific solutions, or find a library which would do it for you (like ncurses in the Unix world), but I don't know if any of these fit in your requirements.
You can set the cursor-position on Windows using SetConsoleCursorPosition.
Since you were saying something about VS, I assume restricting yourself to Windows isn't a problem. If so, you can use the Windows API for this.
Other than that, ncurses seems to be at least partially ported to most common platforms.
If you were looking for a way to do this in standard C++ - it doesn't exist. C++ doesn't require the platform it's running on to even have a console, so there are no console manipulation functions.
Both aren't that hard to use, but if this is really just some student thingy where you expect to learn something useful you probably shouldn't bother. Console manipulation isn't something you'll have or want to do very often.
Although it may not have been clear in my original question, I was looking for a solution to be used in a console window. Ideally the solution would have been operable on at least Linux and Windows because any programs I write for school must be compiled on each. This wasn't an assignment but it's obviously advantageous to learn things that are usable there as well.
Here's what I found ...Solution thanks to Tim Wei
void clearScreen()
{
#ifdef _WIN32
system("cls");
#else
system("clear");
#endif
}
This, as simple as it is, was exactly what I was looking for. The function clears the screen and puts the cursor at the top of the console window providing a way to provide static headers or titles with changing data tables. It also allows for simple text based animations - if you like that sort of thing. It made a significant difference in the look, feel and consistency in my console applications this semester!
I'm currently trying to re-write my binder between Ogre and SDL in my game engine. Originally I used the method outlined in the Ogre Wiki here. I recently updated my version of SDL to 1.3 and noticed the "SDL_CreateWindowFrom()" function call and re-implemented my binder to allow Ogre to build the window, and then get the HWND from Ogre to be passed into SDL.
Only one window is made and I see everything renders properly, however no input is collected. I have no idea why. Here's the code I am currently working with (on windows):
OgreWindow = Ogre::Root::getSingleton().createRenderWindow(WindowCaption, Settings.RenderWidth, Settings.RenderHeight, Settings.Fullscreen, &Opts);
size_t Data = 0;
OgreWindow->getCustomAttribute("WINDOW",&Data);
SDLWindow = SDL_CreateWindowFrom(&Data);
SDL_SetWindowGrab(SDLWindow,SDL_TRUE);
I've tried looking around and there are a number of people that have done this to one degree of success or another(such as here or here). But no one seems to comment on handling the input after implementing this.
I originally thought that maybe since SDL does not own the window it wouldn't collect input from it by default, which is reasonable. So I searched the SDL API and only found that one function "SDL_SetWindowGrab()" that seems to relate to input capture. But calling that has no effect.
How can I get SDL to collect input from my Ogre-made window?
It has been a while, but I figured I would put in the answer for others that may need it. It turned out to be a bug/incomplete feature in SDL 1.3. The "CreateWindowFrom" method wasn't originally intended to be used exclusively as an input handler. At the time of this writing I know myself and another on my team wrote patches for Windows and Linux that permitted this use to work and submitted those patches to SDL.
Basically what I am trying to do is write my own pseudo task bar in C++. The program needs to idle until another program is started up, at which point it needs to visually depict that the other program is running. For each other program that is running, the user should be able to click on the visual representation and have Windows switch focus to the selected program.
The big underlying question at this point: is this even a possibility? Or has Windows hidden most/all of its fiddly-bits to make this close to, if not completely, impossible?
[EDIT:] restructured the question
The obvious starting point would be SetWindowsHookEx(WH_SHELL,...); which will get you notifications when top-level windows are created or destroyed (along with some other related events, like a different window being activated, a window's title changing, etc.)
Think ahead to actually bringing the window to the front, as I once researched myself.
SetForegroundWindow() won't work unless issued from the foreground process - neither SwitchToThisWindow() nor the AttachThreadInput() kludge seemed to always work, but maybe I just wasn't doing it right. Anyway as far as I know there no way to make a window foreground as good as Windows does, please enlighten me if say you discover say an undocumented call which actually Works.
It seems possible to me at least in a basic way:
1. Set up a shell hook as described by Jerry
2. figure the executable file from the module handle to access it's icons using shell services
The Vista-like feature of keeping a 'live' miniature of the screen seems much more challenging.