- User Since
- Dec 12 2013, 11:11 PM (296 w, 6 d)
Dalai and I agreed on merging T47899 into this. The old task can still be referred to, but development took new paths that are better discussed here. We'd also like to discuss things on a broader level - the big picture for VR in Blender.
Will publish more info soon.
Tue, Aug 20
Added some inline notes for reviewers.
Note that I also plan to add/improve comments on API functions.
The file browser redesign which is currently in progress involved similar changes, see T62971. So the solutions chosen should be consistent across the outliner and the file browser.
This is an older screenshot, although I think not much has changed in the popovers since then:
Mon, Aug 19
Sat, Aug 17
Wed, Aug 14
The UNKNOWN ENUM print should be fixed with rBb7f86ff7227.
I guess this report can be closed. Although I'd still suggest to use Area.ui_type rather than Area.type for this add-on.
- Merge branch 'master' into arcpatch-D5325
- Fix mistake (was unlikely to ever cause issues)
- Minor cleanup: Variable declaration/definition order + use const
Mon, Aug 12
Please create a proper bug report with all requested information given. You'll also have to speak english here, there's not much we can do for you otherwise.
Sun, Aug 11
Previous comments are correct. This seems to work as designed. Closing the report.
Fri, Aug 9
Right, we wouldn't want to be too intrusive for info or low-importance warning messages. A bit of color and animation can be handy to draw the users eye here, but an overlapping popup would be too much.
OTOH important messages like errors should be intrusive - when we get one, the workflow was already disrupted, the message just exposes and explains that fact. So IMHO a popup is fine here.
Since this gets into the idea of repurposing of the info editor, I'd recommend checking out what we've considered during the UI workshop: https://archive.blender.org/wiki/index.php/Dev:2.8/UI/Workshop_Writeup/#Info_Editor. The full info editor should always be reachable from the status bar (e.g. a More button could spawn the info editor in full screen, or as separate temp window). So basically the status bar would be the short version of the Info Editor, the latter containing all details.
Wed, Aug 7
It's not that I expect a big performance gain from a separate drawing thread. But we can avoid overhead of the main loop and OpenGL context switches using a separate thread. Currently this gives me about +11 FPS in the classroom scene. The other reason is that OpenXR runtimes perform blocking calls for frame synchronization, also blocking the rest of Blender. I've also outlined the reasons here: https://devtalk.blender.org/t/gsoc-2019-core-support-of-virtual-reality-headsets-through-openxr/7614/28.
Tue, Aug 6
Did a few more tests, that is, running Blender and letting it execute gpu_context_active_matrix_state_get 1.000.000 times. Either accessing the matrix state as a static or a static thread_local. Again compiled on latest MSVC. I ran three passes.
Just checked Clang ouput with optimizations enabled (O1 and higher), and it also solves it without the extra function call:
getNumber(): # @getNumber() movsd xmm0, qword ptr fs:[number@TPOFF] # xmm0 = mem,zero ret
I find it a bit hard to reason about this. There are some older post describing why it is or was slow (https://stackoverflow.com/questions/13106049/what-is-the-performance-penalty-of-c11-thread-local-variables-in-gcc-4-8, https://software.intel.com/en-us/blogs/2011/05/02/the-hidden-performance-cost-of-accessing-thread-local-variables/). Newer posts seem more optimistic (https://stackoverflow.com/questions/32245103/how-does-the-gcc-thread-work). But ultimately, this is of course heavily platform/implementation dependant.
Mon, Aug 5
- Cleanup: Remove unnecessary call & var
- Share code of new functions in resources.c
- Cover all UI_GetTheme calls in draw manager
Yikes, indeed there are quite a few more calls to be covered. Wrote this while traveling so wasn't too attentive...
Sun, Aug 4
Sat, Aug 3
Fri, Aug 2
Wed, Jul 31
Tue, Jul 30
Mon, Jul 29
Sun, Jul 28
Fri, Jul 26
Note that there are two vastly different meanings of "sticky keys". On Windows, it's the name of an accessibility feature, where pressing a modifier key would leave it pressed until... pressed again I think? (Please correct me). I guess this is what's being referred to here. For us, and I'm not sure if we've taken the name from somewhere else, sticky keys usually refers to the ability to differntiate between a tap, and a hold of a key.
Thu, Jul 25
Wed, Jul 24
I guess this should be available everywhere in the editor. @Jacques Lucke (JacquesLucke) you were the one doing changes here, did you change this intentionally?
In list view, it would be very nice to support shift-clicking to select in-between, ctrl to extend selections.
This already works. Shift selecting extends, Shift + Ctrl fills. I guess the extra Shift is needed because Ctrl only is used for renaming. I guess we could check if there's already a file selected as better differentiation.
All in all the selection could use some rework. E.g. you still need to use RMB to select folders. Can do that after this redesign.
Tue, Jul 23
Versioning is a bit difficult for this. Can't avoid some tradeoffs.
Jul 23 2019
Current state of the implementation looks like this:
I'd say it's close to being ready. No bigger TODOs are left on my list.
TIMELINE is now DOPESHEET_EDITOR with its mode set to TIMELINE. The Add-on may be better off using the Area.ui_type enum though (see https://docs.blender.org/api/current/bpy.types.Area.html#bpy.types.Area.ui_type), which is the same enum used for generating the regular editor dropdown and includes all the editor sub-types.
We've just talked about this on chat.blender.org, so leaving a quick comment here: VSE should probably get a way to display the "Adjust last Operations" panel (Operator redo). That way operator settings could be tweaked after the operation. Added item to the TODO list, T55366.
Jul 22 2019
Jul 21 2019
I'm probably the one who did most changes for 2.80 in relating code. And I didn't remember ever seeing special treatment of split regions, which made me wonder how this could ever work before.
Turns out we added the AZone's during region size updating, at a point where the prev region was temporarily using a winrct of both regions combined. So of course a single AZone spanning both regions would be added.