When will the assertions in the below code fire?
let orien = UIApplication.shared.statusBarOrientation
UIDevice.current.beginGeneratingDeviceOrientationNotifications()
switch UIDevice.current.orientation {
case .portrait: assert(orien == .portrait)
case .portraitUpsideDown: assert(orien == .portraitUpsideDown)
case .landscapeLeft: assert(orien == .landscapeRight)
case .landscapeRight: assert(orien == .landscapeLeft)
default: return
}
When your app doesn't support all four orientations. UIDeviceOrientation reflects the orientation of the device independent of whether your app supports that orientation. statusBarOrientation will always be one of the orientations you support.
So, for example, if your device is in portrait upside down, but your app doesn't support that orientation, UIDeviceOrientation will be portraitUpsideDown, but statusBarOrientation will be landscapeLeft (if that was the orientation the device was in prior to portrait upside down).
Note that rotation lock on the iPhone won't make the assertions above fire — both statusBarOrientation and UIDeviceOrientation are reported as portrait, independent of the actual orientation, but they're consistent with each other.
Related
Using Media Foundation, I'm trying to capture the screen and record and render it with EVR at the same time. I've written a custom media source for this. It works almost perfectly.
The only problem is, by default without reversing the image, EVR renders the screen correctly, but the recorded video is vertically flipped. I'm literally passing the same IMFSample to the sinks. I reversed the image and it records just fine, but now EVR renders it vertically flipped. Why are EVR and sink writer inconsistent and is there a solution for this problem?
Other possibly useful information:
Capture method: Buffer swapping with DirectX9
Media type:
check = MFExtern.MFCreateMediaType(out var mediaType);
check = mediaType.SetGUID(MFAttributesClsid.MF_MT_MAJOR_TYPE, MFMediaType.Video);
check = mediaType.SetGUID(MFAttributesClsid.MF_MT_SUBTYPE, MFMediaType.RGB32);
check = mediaType.SetUINT32(MFAttributesClsid.MF_MT_INTERLACE_MODE, (uint)MFVideoInterlaceMode.Progressive);
check = mediaType.SetSize(MFAttributesClsid.MF_MT_FRAME_SIZE, (uint)mode.Width, (uint)mode.Height);
check = mediaType.SetRatio(MFAttributesClsid.MF_MT_FRAME_RATE, FrameRateNumerator, FrameRateDenominator);
check = mediaType.SetRatio(MFAttributesClsid.MF_MT_PIXEL_ASPECT_RATIO, 1, 1);
check = mediaType.SetBoolean(MFAttributesClsid.MF_MT_ALL_SAMPLES_INDEPENDENT, true);
I was running the http://browserbench.org/MotionMark/ benchmark in JxBrowser 6.14 in Heavyweight & Lightweight mode, when i noticed, that the iframe used by the benchmark gets a different size for the two modes:
My Frame size: 1000x800
Heavyweight iframe: 900x600
The Benchmark says at the end: "on a medium screen (laptop, tablet)"
The <body> is flagged with the class medium.
Lightweight iframe: 568x320
The Benchmark says at the end: "on a small screen(phone)"
The <body> is flagged with the class small.
The code of the website responsible for this difference is this:
determineCanvasSize: function() {
var match = window.matchMedia("(max-device-width: 760px)");
if (match.matches) {
document.body.classList.add("small");
return;
}
match = window.matchMedia("(max-device-width: 1600px)");
if (match.matches) {
document.body.classList.add("medium");
return;
}
match = window.matchMedia("(max-width: 1600px)");
if (match.matches) {
document.body.classList.add("medium");
return;
}
document.body.classList.add("large");
},
So apparently these matchMedia() queries behave differently in Lightweight mode and Heavyweight mode.
But why should they?
And what could be a solution?
I'm not aware how this benchmark works, but I know that heavyweight and lightweight rendering modes in JxBrowser are too completely different modes that have their own advantages and limitations. Maybe the issue you see is one of them. As far as I know in the lightweight rendering mode (off-screen) WebGL might work differently because different render techniques are used in Chromium engine in this case.
Could you please let me know how I can check that the benchmark works differently in both rendering modes? Do I just need to run it in a Java frame with 1000x800 with only embedded BrowserView?
I'm trying to implement a very customized implementation of awesome.
I have two monitors. I'd like to have my first client always open on the left monitor (a Chrome window in kiosk mode), then all clients after open up on the right monitor.
Are there any custom layouts that accomodate this?
I'd be willing to program it myself, but I'm not sure how to bind a script to some kind of "new client" event.
The new client event is the manage event. It is emitted whenever, well, a new client gets managed by awesome.
To send the first client that ever appears to screen 1 and all following ones to screen 2, you could do something like this:
local first = true
client.connect_signal("manage", function(c)
if first then
c.screen = 1
else
c.screen = 2
end
first = false
end)
I've implemented a horizontal splitter widget in Xlib. I'm trying to grab the mouse when the user clicks & drags on the splitter bar (so that the user can dynamically move the split & thus resize the windows on either side of the splitter bar).
I've used XGrabPointer() after receiving a left click, in hopes that all future mouse motion (dragging) will be diverted to the splitter window until the left button is released.
Unfortuntately, it doesn't seem to work like that. If the user drags too quickly and the mouse pointer enters one of the windows on either side of the split, the MotionEvent messages are diverted to that (child) window rather than the splitter window.
What have I done wrong? My XGrabPointer() call is as follows:
::XGrabPointer(mDisplay, window, True,
ButtonPressMask |
ButtonReleaseMask |
PointerMotionMask |
FocusChangeMask |
EnterWindowMask |
LeaveWindowMask,
GrabModeAsync,
GrabModeAsync,
RootWindow(mDisplay, DefaultScreen(mDisplay)),
None,
CurrentTime);
I'm almost embarrassed to admit this, but the answer turned out to be as simple as changing that third parameter (owner_events) from True to False.
From the Xlib tutorial/reference at tronche.com:
If owner_events is False, all generated pointer events are reported with respect to grab_window and are reported only if selected by event_mask. If owner_events is True and if a generated pointer event would normally be reported to this client, it is reported as usual. Otherwise, the event is reported with respect to the grab_window and is reported only if selected by event_mask.
I'm still not sure I completely understand the behavior of the True case, but my interpretation is that if True, other X programs (that is, windows created by other processes) are barred from receiving XEvents, but those that would hit any window created by your process are delivered as normal. In the false case, all events are reported with respect to the specific window you have selected. This was the behavior I was after.
The adobe documentation says that when listening for a keypress event from a phone you should listen for Key.Down, however when I trace the Key.getCode() of keypresses I see a number not the string "Key.Down". I am tesing this locally in device central and do not have a phone to test this with at present. Here is my code -
keyListener = new Object();
keyListener.onKeyDown = function() {
switch (Key.getCode()) {
trace(Key.getCode()) // outputs 40
case (Key.DOWN) : // according to the docs
pressDown();
break;
}
}
My question is - is this simply because Im testing in device central and when I run it on the phone I will need to be listening for Key.Down? or is the documentation wrong? Also is the numeric code (40) consistent across all devices? What gives adobe?
thanks all
Key.Down is equal to 40 so it will recognize it as the same. So you can use whichever one you prefer, however, I would recommend using Key.Down because it will be easily recognizeable for those who dont have Key Codes memorized (most of us).
These are the Key Code Values for Javascript. However, I think they are pretty much universal