I am developing an iOS application that comes pre-loaded with CoreData content.
I am trying to create an importer app for the Mac OS X command-line which uses the same xcdatamodel and imports the initial data that I can ship with the actual app.
So far, so good.
One of the fields in the model, however, is a transformable in which I want to store a Bezier path. Unfortunately, Mac OS X uses NSBezierPath while iOS uses UIBezierPath to store bezier paths.
Is there any way of using the binary UIBezierPath class (and its header file) from the iOS Simulator platform in my OS X project?
I don’t want to convert my project to run in the simulator because I want to be able to run it from the command-line and pass arguments.
There should be a way to make this work, shouldn’t there? Because the simulator platform is compiled for the Mac’s architecture and no GUI components are ever used.
I am also looking for other (creative?) ways to solve this problem… A custom NSValueTransformer, perhaps, or a reverse-engineering of UIBezierPath’s NSCoding adaptation?
Maybe I am just too narrow-minded, too focused on what will essentially turn out to be a futile attempt. Please feel free to point this out in your answer if you think it’s the case…
The library CKBezierPath emulates the NSBezierPath for iOS. Not tested, but give it a try. ;-)
Ken Ferry (Apple engineer from the Cocoa frameworks team):
The keyed archive container format is
interchangeable, however whether a
particular archive is interchangeable
depends on what's in it. Obviously if
a class is only present on one of iOS
and Mac OS X, that's a problem. For
arbitrary individual classes present
on both OSes, it's difficult to say
anything too concretely. People may
have taken advantage of the new OS to
drop some aspects of compatibility.
If your keyed archive contains
exclusively Foundation classes, it's
our intent that they should be as
interchangeable between iOS and Mac OS
X as between versions of Mac OS X. I
don't think we have specific tests to
make sure it works, though, so, well,
if it doesn't for something, file a
bug.
NSBezierPath is AppKit though, so you have to fall back to reverse engeneering. It might not be too difficult because UIBezierPath and NSBezierPath probably both depend on CGPath, but that's only a guess.
Related
I have two monitors, each connected to a different GPU. Both GPUs are in a single machine, and I want to run a single application. I have two independent views, and I would like to render each one using a GPU/Monitor set. I can create multiple surfaces and devices, but I want to ensure I associate each surface with the GPU its monitor is plugged into, otherwise I suspect I'll suffer performance issues as the frame buffers need to be copied back and forth between cards.
I'm using fullscreen surfaces, and I was thinking this was something vkGetPhysicalDeviceSurfaceSupportKHR would tell me. However, both VkSurfaceKHR appear to be valid targets for each VkPhysicalDevice so I guess this is something the OS and GPU Driver can handle, but is there any hint about which surface is optimal to associate with a device?
From what I can tell the extension VK_KHR_display is one way of doing this, but it's not available on my Windows 10 machine or Nvidia GPU. It seems to be intended for embedded platforms only. However it lets you list attached displays for each device which is pretty much what I'm looking for: https://vulkan.lunarg.com/doc/view/1.0.30.0/linux/vkspec.chunked/ch29s03.html
This quote from the docs makes me belive this may not be supported on Windows:
Issues
1) Does Win32 need a way to query for compatibility between a particular physical device and a specific screen? Compatibility between a physical device and a window generally only depends on what screen the window is on. However, there is not an obvious way to identify a screen without already having a window on the screen.
RESOLVED: No. While it may be useful, there is not a clear way to do this on Win32. However, a method was added to query support for presenting to the windows desktop as a whole.
However, I'm still interested in hearing if there's a work around to achieve a similar effect.
Finally figured out a work around for this:
Direct X actually supports this through use of the IDXGIAdapter::EnumOutputs function. This lets you list the monitors connected to each GPU. Then using these two extensions you can remap this information to Vulkan:
VK_KHR_external_memory_capabilities
VK_KHR_get_physical_device_properties2
You can use these to get the deviceLUID from VkPhysicalDeviceIDPropertiesKHR.
This can then be compared with the Luid from this structure in Direct X DXGI_ADAPTER_DESC
You can also use glfwGetWin32Window to get the HWND of the monitor. This lets you associate a vulkan surface with a direct x monitor.
You now have all the information you need to accociate vulkan surfaces with the devices they're actually connected to.
At least in my application, setting this up correctly results in a significant difference in performance.
This would all be way simpler (and cross platform) if Windows would just support the VK_KHR_display and VK_KHR_display_swapchain extensions as Linux does.
There are two extensions that are useful for such things: the one mentioned by You, VK_KHR_display and the second called VK_KHR_display_swapchain which allows You to create a swapchain directly on a device’s display without any underlying window system.
But these extensions are rarely supported on Windows. In core Vulkan API there is no way to achieve what You want. And I'm afraid You need to use OS-specific functions (You need to rely on the WinAPI functions in this situation).
[EDIT]
Did You saw this question? How can you get the display adapter used for a particular monitor in Windows? If not, maybe it will help You start with Your research.
As you already discovered, on Win32 you need to use the OS windowing system to pick the display you want to use, using the Window API. It can be straight forward.
BUT if you intend to make simple and agnostic OS code, check GLFW project. It has high level functions to handle windows on all major OSs.
Check :
GLFW monitor Guide
GLFW Vulkan integration
GLFW on its own words:
GLFW is a free, Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan application development. It provides a simple, platform-independent API for creating windows, contexts and surfaces, reading input, handling events, etc.
I can get the list of available printer fonts by calling Delphi's TPrinter methods which I believe in turn calls Windows GDI (such as CreateFontA() ?). I do this in WINE running in Debian. I do not know why, but luckily this list contains true type font names, which I need most but are not shown by command xlsfonts. I am not sure if this is relevant to the technology under the hood, but package CUPS is installed.
This successful experience makes me to think that WINE must in turn call some Linux API (X, xfs, ...?) and then provide my program the results I want.
Now I would like to get the same list directly from Linux in C or C++. Which way should I take in order to achieve this goal? What API documentations should I study?
WINE font inspires me a lot, but I decide to stop researching the solution for my own question as the technology required to retrieve printer fonts in X window seems to be not trivial. I choose to use the font list given by Delphi's TPrinter running in WINE instead.
I close this question.
Can you provide me a surface level knowledge about this.
How can I use linux's latest kernel and X windows GUI to create my own Embedded OS interface?
If you want to learn to make your own distribution, look at linux from scratch. A pre-existing embedded distribution may be more what you are looking for. Some are uclinux-dist, openembedded, poky, ltib, buildroot.
When you say "small" what do you mean by small? Small means reduced functionality.
The smallest is writing your own code that writes to the frame buffer. Your GUI may look like space invaders.
Bigger would be to use a direct to framebuffer toolkit like Nano-X
Bigger again is DirectFB.
Bigger again is a high level toolkit
(GTK or Qt) on top of DirectFB
And the biggest is X with a window
manager and high level toolkit.
Having "learned" already, I would use whatever comes with the platform you are developing on.
End Dump.
First suggestion, code HTML and use a browser. All of the heavy lifting will be done for you. More to the point, most embedded OSen do not live on systems with keyboards, video, and mice. Exporting everything to a remote web client though a web server is the standard way of doing things.
Second suggestion, use a high level toolkit, like Qt, KDE, or Gnome. Coding in low level X is painful.
I am writing an OpenGL game which will hopefuflly be for both linux and iphoneOS, I basically want to be able to build using the OpenGL ES 1.5 headers and run it on my linux desktop. Can I do this? IE, I want to only use the subset of API calls common between OpenGL and OpenGL-ES.
Doing the above and linking with normal libGL.a from my system gets me my screen but I seem to be able to do nothing but change the scene background colour.
I've done exactly that, and it worked well for me.
There are a bunch OpenGL|ES extensions that aren't available on standard OpenGL but very nice to have on a low spec platform. glDrawTexImage is such an extension. Emulating these extensions using a hand full of desktop OpenGL-calls is not a big deal though.
Also OpenGL|ES supports the fixed-point data-format for most entrypoints. Take glClearColorx for example. These aren't available for the desktop OpenGL, so you have to write a wrapper if you want to use them. It's a bit more work if you also store your vertex data in this format.
Oh - and note that OpenGL|ES does not come with the glu-library. You can use it on the desktop, but if you do you'll have to reimplement them later (see the 100 questions about gluLookAt and gluUnproject).
There is no such thing as OpenGL ES 1.5. Did you mean 1.1 ?
Also, how do you get a window ? This is platform specific.
In any case, you still should compile against the header that corresponds to the lib you will link against. You don't know for sure what the header sets up (e.g. on windows, which you don't care about but still, calling conventions are specified in there).
There are also some calls that don't map well between the 2. E.g. APIs that are only using doubles in GL are float in GLES (from the ES spec):
The double-precision only commands
DepthRange, Frustum, and Ortho are
replaced with single-precision or
fixed-point variants
So in short, there is a bit more work than just using the same code, although the work in question is still minimal if you stick to GL ES subset.
I woud like to create a cross-platform drawing program. The one requirement for writing my app is that I have pixel level precision over the canvas. For instance, I want to write my own line drawing algorithm rather than rely on someone elses. I do not want any form of anti-aliasing (again, pixel level control is required.) I would like the users interactions on the screen to be quick and responsive (pending my ability to write fast algorithms.)
Ideally, I would like to write this in Python, or perhaps Java as a second choice. The ability to easily make the final app cross-platform is a must. I will submit to different API's on different OS'es if necessary as long as I can write an abstraction layer around them. Any ideas?
addendum: I need the ability to draw on-screen. Drawing out to a file I've got figured out.
I just this week put together some slides and demo code for doing 2d graphics using OpenGL from python using the library pyglet. Here's a representative post: Pyglet week 2, better vertex throughput (or 3D stuff using the same basic ideas)
It is very fast (relatively speaking, for python) I have managed to get around 1,000 independently positioned and oriented objects moving around the screen, each with about 50 vertices.
It is very portable, all the code I have written in this environment works on windows and Linux and mac (and even obscure environments like Pypy) without me ever having to think about it.
Some of these posts are very old, with broken links between them. You should be able to find all the relevant posts using the 'graphics' tag.
The Pyglet library for Python might suit your needs. It lets you use OpenGL, a cross-platform graphics API. You can disable anti-aliasing and capture regions of the screen to a buffer or a file. In addition, you can use its event handling, resource loading, and image manipulation systems. You can probably also tie it into PIL (Python Image Library), and definitely Cairo, a popular cross-platform vector graphics library.
I mention Pyglet instead of pure PyOpenGL because Pyglet handles a lot of ugly OpenGL stuff transparently with no effort on your part.
A friend and I are currently working on a drawing program using Pyglet. There are a few quirks - for example, OpenGL is always double buffered on OS X, so we have to draw everything twice, once for the current frame and again for the other frame, since they are flipped whenever the display refreshes. You can look at our current progress in this subversion repository. (Splatterboard.py in trunk is the file you'll want to run.) If you're not up on using svn, I would be happy to email you a .zip of the latest source. Feel free to steal code if you look into it.
If language choice is open, a Flash file created with Haxe might have a place. Haxe is free, and a full, dynamic programming language. Then there's the related Neko, a virtual machine (like Java's, Ruby's, Parrot...) to run on Mac, Windows and Linux. Being in some ways a new improved form of Flash, naturally it can draw stuff. http://haxe.org/
QT's Canvas an QPainter are very good for this job if you'd like to use C++. and it is cross platform.
There is a python binding for QT but I've never used it.
As for Java, using SWT, pixel level manipulation of a canvas is somewhat difficult and slow so I would not recommend it. On the other hand Swing's Canvas is pretty good and responsive. I've never used the AWT option but you probably don't want to go there.
I would recommend wxPython
It's beautifully cross platform and you can get per pixel control and if you change your mind about that you can use it with libraries such as pyglet or agg.
You can find some useful examples for just what you are trying to do in the docs and demos download.