Re: [Bf-committers] Blender roadmap article on code blog
On 29/06/2013, at 3:47 PM, Campbell Barton wrote: Mono follows an MS spec for the language runtime (CLR), not sure what the second program you refer to is. At least the technology isn't owned by MS and its open-source. People may be wary of using MS derived technology but from what I can tell Mono wouldn't tie us to MS any more then Java would to Oracle. Unlike the way Java was setup by Sun, Microsoft owns patents required for the CLR C#. Yes, the source code is out in the wide world, but even the FSF has been clear about the threat Microsoft's patents poses to platforms that use the C#. Personally, I don't think that Microsoft gives a damn about Blender (and agree Mono would not tie Blender to them), but should they start to use their patents against someone they *do* care about, it's possible that open-source projects using C#/CLR patents might be caught in the crossfire. Not trying to start a flamewar or anything, and I've used C# in a few projects now (so I'm not adverse to it's use per se), but there are reasons some folks are wary of using C#/Mono in an cross-platform, open-source project. Microsoft uses it's patents aggressively in it's commercial role and there it isn't unreasonable to assume they would use the C#/CLR ones if they see the need. -- Benjamin Tolputt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] DPI scaling question...
On Wed, Jun 26, 2013 at 11:53 PM, Campbell Barton ideasma...@gmail.comwrote: Noticed node placement bug this morning, fixed r57813. Unfortunately, r57813 did not fix the node-placement bug on retina, because the retina bug is related to U.pixelsize ... (see below) Though IMHO using DPI to coords for node placement isn't a good idea (anything besides drawing), but perhaps theres a good reason for it? My instinct, like Brecht, is that DPI and pixelsize shouldn't be seen by most of the C code, and certainly not Python... only coordinate-space transformations, 2d drawing primitives, and a couple places that need to care about pixels. For example, the code currently has lines like: BLF_size(fontid, font point size * U.pixelsize, U.dpi); Which IMO should be changed to hide the DPI and PIXELSIZE inside the abstraction: BLF_size(fontid, font point size); Today, however, this is not how the code handles DPI and PIXELSIZE scaling. I'm guessing we should wait until Ton has the time to tell us if there is a good reason it's done the current way before looking at this bigger picture... In the meantime, I did some digging and I don't think the retina node-placement location bug is related to pixelsize mouse-transforms. I think it's related to drawing code that does not handle pixelsize. Some 2d viewers, including the node editor, do not seem to be handling pixelsize in their local offset and zoom transforms. You can see this because if you drag blender from a retina to non-retina display, these viewers suddenly appear to be at a different zoom level (node, uv-edit, logic, This is fine when transforms are relative. However, when the coordinate is absolute in the view-space, it doesn't align with the drawing coordinates which have not been adjusted for pixelsize. ..at least this is what I think is going on. It's going to take a little more digging to be sure. I think i'll leave this bug until I've fixed some simpler stuff. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] DPI scaling question...
On Fri, Jun 28, 2013 at 11:36 PM, David Jeske dav...@gmail.com wrote: In the meantime, I did some digging and I don't think the retina node-placement location bug is [not] related to pixelsize mouse-transforms. I think it's related to drawing code that does not handle pixelsize. UGH, sorry, is **not** related to pixelsize mouse-transforms.. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] x/y transposes in rna_wm.c? or not?
sorry, nub dev question.. I noticed these entires in rna_wm.c with tooltips saying X positions are vertical, and Y positions are horizontal... Is this the tooltip mistake it seems like to me, or is there some non-obvious reason for this? prop = RNA_def_property(srna, mouse_x, PROP_INT, PROP_NONE); RNA_def_property_int_sdna(prop, NULL, x); RNA_def_property_clear_flag(prop, PROP_EDITABLE); RNA_def_property_ui_text(prop, Mouse X Position, The window relative vertical location of the mouse); ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VS 2013 + Blender = ???
Hi Alex, The libs will not be compatible. All versions of MSVC since 2010 write a version string into libs. And all versions since 2012 check this string. You can not link to libs compiled with a older version. Also I can just repeat myself: We don't want to switch to 2013. I would just like to keep track of the changes and try to keep blenders code compatible with future versions. /Jürgen Am 29.06.2013 um 04:23 schrieb Alexandr Kuznetsov kuzsa...@gmail.com: Hi Jürgen and Thomas: From what I understand, they just release the *preview* version of vs 2013. I would advise to wait for the final release due to possible incompatibility between this and final versions (libs wise). I don't see a reason to move to 2013 preview right now. We don't use C++ much and to the full extend (except possibly Cycles) and I'm not aware of that2013 brings C11 support. Also, if you have previous toolkit installed (vs 2012), the 2012 libs should still be compatible with 2013. When 2013 is released, we can drop 2012 as we did with 2010. And still have 2008 as official! As for the patch to the code to make it compliant with c++11, it would be great addition (although gcc doesn't have issues). Best, Alex On 6/28/2013 6:46 PM, Jürgen Herrmann wrote: Hi Thomas, I don't want to update right now, but as ms changed their pace to yearly updates with significant new features and changed compatibilities (e.g more c++11 features) we will have to do a lot of work if we wait 5 years again. As I said I've got a patch for VS 2013 ready and working in my local repo. We could update instantly but I don't want to due to the reasons you stated. I just want to avoid the messy update work we had because we skipped one version. If we skip 5 versions of MSVC (provided that ms keeps this pace) the updating mess will be huge :( So doing a little testing once and a small patch in a while wont hurt, I think. Am 28.06.2013 um 23:27 schrieb Thomas Dinges blen...@dingto.org: Hi Jürgen, We used vc2008 now for like 5 years? or so, and this worked out quite good. Probably we should update more frequently, but I see no reason to rush things either. It will still take some weeks or months to test vc2012 with Blender thoroughly, to use this as a vc2008 replacement for official builds. So let's finish the vc2012 update first, use it for official builds and then worry about when and if we should update the next time. ;) Thomas Am 28.06.2013 23:14, schrieb Jürgen Herrmann: Sure! Switch to MinGw, but please do some good testing ;) I am the last not to support this ;) Am 28.06.2013 um 20:13 schrieb Cezary Kopias cezary.kop...@gmail.com: From USER: As always speed tests must be performed for such a decision. Are there any new VS features that are worth mention? And as always i will promote mingw-w64 :] just read that you can compile windows build under linux - nice /kopias On Fri, 28 Jun 2013 20:08:30 +0200, Jürgen Herrmann shadow...@me.com wrote: Logic error corrected inline ;) Hi there, Out of curiosity I downloaded the VS 2013 Pro preview yesterday. And while playing with it I had the idea to try blender compilation with it ;) I needed to tweak the sources a bit because MSVC 12 seems to break se things as M$ implements more C++11 features. It took me 30 Minutes to put a patch together. But all the libs I compiled with VC11 need to be recompiled :( So I stopped this insanity ... But what I am curious about, what do you guys think? Shall we adapt new versions if MSVC early (even if we don't use it for production) or not? Pro: when we decide to switch to another version (let's assume MSVC 2016, just for an example) the workload of porting might Not be that huge. Con: we have to recompile libs and port blender every year (in case MS keeps this release schedule) /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Using Opera's mail client: http://www.opera.com/mail/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org
[Bf-committers] Patch [#35910] two TINY usability fixes in the node editor
TINY (hopefully uncontroversial) patch to fix up to parent usability in the node-editor (and improve a tooltip) http://projects.blender.org/tracker/index.php?func=detailaid=35910group_id=9atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] A better way to display the Weight value in weight Paint mode ?
Hi; I know this breaks every rule of the Blender user interface. However please take a moment (or two) and think about these 2 alternatives for showing the Weight paint value in weight Paint mode: http://pasteall.org/pic/show.php?id=54510 On the left side: the bar changes its color from blue to red depending on the weight value. On the right side: the bar reveals a rainbow while the weight value increases. I think using color here is the most intuitive representation that is possible when working with weight values. And its practical usage ? Well, when i use the weight value then i always think in colors but i have to specify values between 0 and 1. For me this does not match up nicely. The color bar does a better job here imho. I have not made up my mind which of the alternatives works better. Probably the left one, but i am really not sure. -gaia- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A better way to display the Weight value in weight Paint mode ?
On 29/06/2013 11:04, Gaia wrote: Hi; I know this breaks every rule of the Blender user interface. However please take a moment (or two) and think about these 2 alternatives for showing the Weight paint value in weight Paint mode: http://pasteall.org/pic/show.php?id=54510 On the left side: the bar changes its color from blue to red depending on the weight value. On the right side: the bar reveals a rainbow while the weight value increases. I think using color here is the most intuitive representation that is possible when working with weight values. And its practical usage ? Well, when i use the weight value then i always think in colors but i have to specify values between 0 and 1. For me this does not match up nicely. The color bar does a better job here imho. I have not made up my mind which of the alternatives works better. Probably the left one, but i am really not sure. -gaia- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Some users can use a custom weight paint gradient from black to white . In this case, RGB color is irrelevant and replacing it by BW could hide weight value. ronan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [57845] trunk/blender/source/blender: Fix #35884: crash opening . blend with generated color grid image and preview render.
Hi Brecht,
Buildbot, scons compile error in Windows:
Compiling == 'blf.c'
blf.c
source\blender\blenlib\BLI_threads.h(38) : fatal error C1083: Cannot open
include file: 'pthread.h': No such file or directory
scons: building terminated because of errors.
No idea why... Windows include files is not my territory :)
-Ton-
Ton Roosendaal - t...@blender.org - www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A - 1018AD Amsterdam - The Netherlands
On 28 Jun, 2013, at 15:05, Brecht Van Lommel wrote:
Revision: 57845
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=57845
Author: blendix
Date: 2013-06-28 13:05:15 + (Fri, 28 Jun 2013)
Log Message:
---
Fix #35884: crash opening .blend with generated color grid image and preview
render.
Printing text on the color grid image would initialize font glyphs from a
thread at
the same time as the UI, causing conflicts. The freetype glyph renderer needs
to be
mutex locked because it uses a shared buffer internally even when rendering
for
different fonts. Also needed to change the image generate function to use the
render
monospace font to avoid conflicts in blenfont.
What's still weak in the blenfont API is that there is no distinction between
a font
and a thread using that font to render with some particular size, style, etc.
Modified Paths:
--
trunk/blender/source/blender/blenfont/intern/blf.c
trunk/blender/source/blender/blenfont/intern/blf_dir.c
trunk/blender/source/blender/blenfont/intern/blf_font.c
trunk/blender/source/blender/blenfont/intern/blf_glyph.c
trunk/blender/source/blender/blenfont/intern/blf_internal_types.h
trunk/blender/source/blender/blenkernel/intern/image_gen.c
Modified: trunk/blender/source/blender/blenfont/intern/blf.c
===
--- trunk/blender/source/blender/blenfont/intern/blf.c2013-06-28
06:54:49 UTC (rev 57844)
+++ trunk/blender/source/blender/blenfont/intern/blf.c2013-06-28
13:05:15 UTC (rev 57845)
@@ -44,6 +44,7 @@
#include DNA_vec_types.h
#include BLI_math.h
+#include BLI_threads.h
#include BIF_gl.h
#include BLF_api.h
Modified: trunk/blender/source/blender/blenfont/intern/blf_dir.c
===
--- trunk/blender/source/blender/blenfont/intern/blf_dir.c2013-06-28
06:54:49 UTC (rev 57844)
+++ trunk/blender/source/blender/blenfont/intern/blf_dir.c2013-06-28
13:05:15 UTC (rev 57845)
@@ -46,6 +46,7 @@
#include BLI_listbase.h
#include BLI_path_util.h
#include BLI_string.h
+#include BLI_threads.h
#include BIF_gl.h
Modified: trunk/blender/source/blender/blenfont/intern/blf_font.c
===
--- trunk/blender/source/blender/blenfont/intern/blf_font.c 2013-06-28
06:54:49 UTC (rev 57844)
+++ trunk/blender/source/blender/blenfont/intern/blf_font.c 2013-06-28
13:05:15 UTC (rev 57845)
@@ -48,6 +48,7 @@
#include BLI_rect.h
#include BLI_string.h
#include BLI_string_utf8.h
+#include BLI_threads.h
#include BLI_linklist.h /* linknode */
#include BIF_gl.h
@@ -64,15 +65,18 @@
/* freetype2 handle ONLY for this file!. */
static FT_Library ft_lib;
+static SpinLock ft_lib_mutex;
int blf_font_init(void)
{
+ BLI_spin_init(ft_lib_mutex);
return FT_Init_FreeType(ft_lib);
}
void blf_font_exit(void)
{
FT_Done_FreeType(ft_lib);
+ BLI_spin_end(ft_lib_mutex);
}
void blf_font_size(FontBLF *font, unsigned int size, unsigned int dpi)
@@ -572,6 +576,7 @@
font-buf_info.col[3] = 0;
font-ft_lib = ft_lib;
+ font-ft_lib_mutex = ft_lib_mutex;
}
FontBLF *blf_font_new(const char *name, const char *filename)
Modified: trunk/blender/source/blender/blenfont/intern/blf_glyph.c
===
--- trunk/blender/source/blender/blenfont/intern/blf_glyph.c 2013-06-28
06:54:49 UTC (rev 57844)
+++ trunk/blender/source/blender/blenfont/intern/blf_glyph.c 2013-06-28
13:05:15 UTC (rev 57845)
@@ -48,6 +48,7 @@
#include BLI_listbase.h
#include BLI_rect.h
+#include BLI_threads.h
#include BIF_gl.h
#include BLF_api.h
@@ -224,6 +225,19 @@
if (g)
return g;
+ /* glyphs are dynamically created as needed by font rendering. this
means that
+ * to make font rendering thread safe we have to do locking here. note
that this
+ * must be a lock for the whole library and not just per font, because
the font
+ * renderer uses a shared buffer internally */
+ BLI_spin_lock(font-ft_lib_mutex);
+
+ /* search again after locking */
+ g = blf_glyph_search(font-glyph_cache, c);
+ if (g) {
+
Re: [Bf-committers] DPI scaling question...
Hi, I tried to add DPI scaling and retina (pixelsize) support in the least intrusive way for the code. The button views (layout engine) behave very nice for it. Similarly easy was for 3D views, FCurve editor, Image, etc. However, Node Editor is an exception. It uses 2D elements (nodes) and UI widgets together in 1 view matrix. I choose to make it work using the way how views for UI widgets work, but that meant it had to handle the view scaling for node drawing itself differently. It think it's acceptable, also because it was my impression we would look into reducing (or even remove) UI widgets in nodes in future anyway. That's the main 'bad' exception for HiDPI in Blender code now. (Plus a hack in window manager to wrap window sizes). Everything is under the hood so can be redesigned in other ways too. -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 27 Jun, 2013, at 13:43, Brecht Van Lommel wrote: On Thu, Jun 27, 2013 at 9:38 AM, David Jeske dav...@gmail.com wrote: ...which brings us back to my original question. Why is DPI exposed to so much blender code? If there was a virtual coordinate system and DPI/PIXEL scaling was hidden, then none of these places would know about DPI, node placement would be right, and node spacing would be consistent. Is this to avoid a wrapper around the GL calls for 2d operations? Does that overhead matter? They could be inlined. I don't know the reason behind this, Ton decided to do it this way when he worked on DPI and later retina support. I would have implemented it at a lower level too in the UI code, though maybe not as an OpenGL wrapper because you still want to round to integer coordinates for final button drawing I think, or have line thickness of 1 or 2, not 1.5 if you want things to draw crisp. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [57871] trunk/blender/source/blender/ blenkernel/intern/mesh.c: fixed Blender crash, but unclear when this situation can happen
Is there any more information you have about this, like a bug report
or a description of when this happens? Now it's adding an XXX comment
but there's no information for someone who might want to fix the
actual bug.
On Sat, Jun 29, 2013 at 10:38 AM, Gaia Clary
gaia.cl...@machinimatrix.org wrote:
Revision: 57871
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=57871
Author: gaiaclary
Date: 2013-06-29 08:38:17 + (Sat, 29 Jun 2013)
Log Message:
---
fixed Blender crash, but unclear when this situation can happen
Modified Paths:
--
trunk/blender/source/blender/blenkernel/intern/mesh.c
Modified: trunk/blender/source/blender/blenkernel/intern/mesh.c
===
--- trunk/blender/source/blender/blenkernel/intern/mesh.c 2013-06-29
07:00:38 UTC (rev 57870)
+++ trunk/blender/source/blender/blenkernel/intern/mesh.c 2013-06-29
08:38:17 UTC (rev 57871)
@@ -3938,7 +3938,10 @@
{
BLI_assert(ELEM3(type, ME_VSEL, ME_ESEL, ME_FSEL));
- if (me-totselect) {
+ /* XXX how can it be that sometimes me-mselect is NULL here ?
+ It happens, but its not clear why it happens!
+ */
+ if (me-totselect me-mselect) {
if (me-mselect[me-totselect - 1].type == type) {
return me-mselect[me-totselect - 1].index;
}
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [57845] trunk/blender/source/blender: Fix #35884: crash opening . blend with generated color grid image and preview render.
Fixed now.
On Sat, Jun 29, 2013 at 12:05 PM, Ton Roosendaal t...@blender.org wrote:
Hi Brecht,
Buildbot, scons compile error in Windows:
Compiling == 'blf.c'
blf.c
source\blender\blenlib\BLI_threads.h(38) : fatal error C1083: Cannot open
include file: 'pthread.h': No such file or directory
scons: building terminated because of errors.
No idea why... Windows include files is not my territory :)
-Ton-
Ton Roosendaal - t...@blender.org - www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A - 1018AD Amsterdam - The Netherlands
On 28 Jun, 2013, at 15:05, Brecht Van Lommel wrote:
Revision: 57845
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=57845
Author: blendix
Date: 2013-06-28 13:05:15 + (Fri, 28 Jun 2013)
Log Message:
---
Fix #35884: crash opening .blend with generated color grid image and preview
render.
Printing text on the color grid image would initialize font glyphs from a
thread at
the same time as the UI, causing conflicts. The freetype glyph renderer
needs to be
mutex locked because it uses a shared buffer internally even when rendering
for
different fonts. Also needed to change the image generate function to use
the render
monospace font to avoid conflicts in blenfont.
What's still weak in the blenfont API is that there is no distinction
between a font
and a thread using that font to render with some particular size, style, etc.
Modified Paths:
--
trunk/blender/source/blender/blenfont/intern/blf.c
trunk/blender/source/blender/blenfont/intern/blf_dir.c
trunk/blender/source/blender/blenfont/intern/blf_font.c
trunk/blender/source/blender/blenfont/intern/blf_glyph.c
trunk/blender/source/blender/blenfont/intern/blf_internal_types.h
trunk/blender/source/blender/blenkernel/intern/image_gen.c
Modified: trunk/blender/source/blender/blenfont/intern/blf.c
===
--- trunk/blender/source/blender/blenfont/intern/blf.c2013-06-28
06:54:49 UTC (rev 57844)
+++ trunk/blender/source/blender/blenfont/intern/blf.c2013-06-28
13:05:15 UTC (rev 57845)
@@ -44,6 +44,7 @@
#include DNA_vec_types.h
#include BLI_math.h
+#include BLI_threads.h
#include BIF_gl.h
#include BLF_api.h
Modified: trunk/blender/source/blender/blenfont/intern/blf_dir.c
===
--- trunk/blender/source/blender/blenfont/intern/blf_dir.c2013-06-28
06:54:49 UTC (rev 57844)
+++ trunk/blender/source/blender/blenfont/intern/blf_dir.c2013-06-28
13:05:15 UTC (rev 57845)
@@ -46,6 +46,7 @@
#include BLI_listbase.h
#include BLI_path_util.h
#include BLI_string.h
+#include BLI_threads.h
#include BIF_gl.h
Modified: trunk/blender/source/blender/blenfont/intern/blf_font.c
===
--- trunk/blender/source/blender/blenfont/intern/blf_font.c 2013-06-28
06:54:49 UTC (rev 57844)
+++ trunk/blender/source/blender/blenfont/intern/blf_font.c 2013-06-28
13:05:15 UTC (rev 57845)
@@ -48,6 +48,7 @@
#include BLI_rect.h
#include BLI_string.h
#include BLI_string_utf8.h
+#include BLI_threads.h
#include BLI_linklist.h /* linknode */
#include BIF_gl.h
@@ -64,15 +65,18 @@
/* freetype2 handle ONLY for this file!. */
static FT_Library ft_lib;
+static SpinLock ft_lib_mutex;
int blf_font_init(void)
{
+ BLI_spin_init(ft_lib_mutex);
return FT_Init_FreeType(ft_lib);
}
void blf_font_exit(void)
{
FT_Done_FreeType(ft_lib);
+ BLI_spin_end(ft_lib_mutex);
}
void blf_font_size(FontBLF *font, unsigned int size, unsigned int dpi)
@@ -572,6 +576,7 @@
font-buf_info.col[3] = 0;
font-ft_lib = ft_lib;
+ font-ft_lib_mutex = ft_lib_mutex;
}
FontBLF *blf_font_new(const char *name, const char *filename)
Modified: trunk/blender/source/blender/blenfont/intern/blf_glyph.c
===
--- trunk/blender/source/blender/blenfont/intern/blf_glyph.c 2013-06-28
06:54:49 UTC (rev 57844)
+++ trunk/blender/source/blender/blenfont/intern/blf_glyph.c 2013-06-28
13:05:15 UTC (rev 57845)
@@ -48,6 +48,7 @@
#include BLI_listbase.h
#include BLI_rect.h
+#include BLI_threads.h
#include BIF_gl.h
#include BLF_api.h
@@ -224,6 +225,19 @@
if (g)
return g;
+ /* glyphs are dynamically created as needed by font rendering. this
means that
+ * to make font rendering thread safe we have to do locking here. note
that this
+ * must be a lock for the whole library and not just per font, because
the font
+ * renderer uses a shared buffer internally */
+ BLI_spin_lock(font-ft_lib_mutex);
+
+ /* search again after locking */
+ g =
Re: [Bf-committers] x/y transposes in rna_wm.c? or not?
Fixed now, these were indeed wrong, just a silly typo/mixup. On Sat, Jun 29, 2013 at 8:46 AM, David Jeske dav...@gmail.com wrote: sorry, nub dev question.. I noticed these entires in rna_wm.c with tooltips saying X positions are vertical, and Y positions are horizontal... Is this the tooltip mistake it seems like to me, or is there some non-obvious reason for this? prop = RNA_def_property(srna, mouse_x, PROP_INT, PROP_NONE); RNA_def_property_int_sdna(prop, NULL, x); RNA_def_property_clear_flag(prop, PROP_EDITABLE); RNA_def_property_ui_text(prop, Mouse X Position, The window relative vertical location of the mouse); ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] DPI scaling question...
Hi, This line: y = (ypixels = 39.0f * UI_DPI_FAC) ? (ypixels - 10.0f * UI_DPI_FAC) : 29.0f * UI_DPI_FAC; Is really an exception. It was code using hardcode pixel values before. So it was this: y = (ypixels = 39.0f) ? (ypixels - 10.0f) : 29.0f; In order to make it respect DPI scaling, the multiplier was added. Best would be to have this multiplication as litte as possible. Most of UI widget code is doing without already. It's just still there for code that was using hardcoded pixels for drawing. The error for node placement on 'add node' is because it's python code trying to do patch DPI stuff, which it shouldn't do there. The API call there (v2d.region_to_view) should have been fixed for it. I'll discuss it with Lukas or Campbell how to solve this best. -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 27 Jun, 2013, at 6:56, David Jeske wrote: I'm trying to fix some Macbook Retina DPI scaling bugs, and I need some background on the UI_DPI_FAC. The first bug is that new compositor nodes are placed wrong on retina. I can see where they are created and placed in scripts/startup/bl_operators. However, I don't understand where DPI scaling is supposed to happen. It surprises me to see code all over which deals with DPI factor like this... y = (ypixels = 39.0f * UI_DPI_FAC) ? (ypixels - 10.0f * UI_DPI_FAC) : 29.0f * UI_DPI_FAC; I expected it to be more centralized, where the whole UI would run in a virtualized coordinate-space automatically adjusted for DPI, and DPI scaling would be handled in the core mouse-event delivery and drawing code. Only a few places that care about raw pixels or should not respond to dpi changes would need to interact with DPI. I suspect there is a reason it wasn't done this way, but I don't know what it is, so it's hard for me to understand where DPI scaling should be done to fix these bugs. Can anyone enlighten me? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] HiDPI notes for other OS'es
Hi, As I explained before, I made MacBook retina to work for HiDPI in the least intrusive way for our code. But I also had to do it in a way it would work for everyone. That meant I had to make two things work independently: - DPI scaling for UIs in general. - Apple's HiDPI implementation Unfortunately these two features were not following an identical specification. That meant I had to seperate it in a Mac-only value (Pixelsize for now) and DPI. For example, a retins dot is default set to be two pixels large. If you start Blender with 72 DPI, it will show visually the same button sizes whether you are in retina mode or not. An important design decision from Apple was to decouple Desktop coordinates from pixels. You can have retina desktops of 1024, 1440, 1920 wide which all get mapped to the actual 2880 screen pixels. But for each desktop width, a dot and standard line widths stay 2 pixels. Still following? :) Mind boggling... especially if you draw the whole UI in OpenGL. I'm still waiting for information how Linux or Windows will address HiDPI. Hopefully in the same way, but probably not... -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [57871] trunk/blender/source/blender/ blenkernel/intern/mesh.c: fixed Blender crash, but unclear when this situation can happen
i got a .blend file from a customer but i can not use that within a bug
report.
The only hints i have so far:
1.) right after the (rigged) object enters weight Paint mode, i can see
in the debugger:
me-totselect = 1
me-mselect = NULL
one vertex has the select flag enabled.
2.) The problem raises when the customer does:
- open the .blend file (now we are in Object mode)
- set the armature to pose mode (works)
- select the object (works)
- enter Weight Paint mode - Crash at the location i commented
I still try to find a simple example to create a bug report for this,
because i suspect the true cause is somewhere else.
But so far i could not recreate a blend file having this problem.
I am still looking at this and try to find out how the customer got
into this state.
-gaia-
On 29.06.2013 12:49, Brecht Van Lommel wrote:
Is there any more information you have about this, like a bug report
or a description of when this happens? Now it's adding an XXX comment
but there's no information for someone who might want to fix the
actual bug.
On Sat, Jun 29, 2013 at 10:38 AM, Gaia Clary
gaia.cl...@machinimatrix.org wrote:
Revision: 57871
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=57871
Author: gaiaclary
Date: 2013-06-29 08:38:17 + (Sat, 29 Jun 2013)
Log Message:
---
fixed Blender crash, but unclear when this situation can happen
Modified Paths:
--
trunk/blender/source/blender/blenkernel/intern/mesh.c
Modified: trunk/blender/source/blender/blenkernel/intern/mesh.c
===
--- trunk/blender/source/blender/blenkernel/intern/mesh.c 2013-06-29
07:00:38 UTC (rev 57870)
+++ trunk/blender/source/blender/blenkernel/intern/mesh.c 2013-06-29
08:38:17 UTC (rev 57871)
@@ -3938,7 +3938,10 @@
{
BLI_assert(ELEM3(type, ME_VSEL, ME_ESEL, ME_FSEL));
- if (me-totselect) {
+ /* XXX how can it be that sometimes me-mselect is NULL here ?
+ It happens, but its not clear why it happens!
+ */
+ if (me-totselect me-mselect) {
if (me-mselect[me-totselect - 1].type == type) {
return me-mselect[me-totselect - 1].index;
}
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
Hi, I had a look at this some months ago. For Windows there is a system DPI that you can configure as a user and there's an API to query it. It does not do this OS X trick with the 2x pixel size and decoupled desktop coordinates, all coordinates are in actual pixels. Here's the info: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660(v=vs.85).aspx There might be some unforeseen issues to solve but a Windows developer might be able to get this working quickly with just a few changes in the code. On Linux I don't know what the solution is, I couldn't even get any desktop environment configured to properly work on my MacBook Retina. Typically the advice seems to be to make the fonts bigger, and tweak some settings to make icons bigger, etc. But that alone doesn't make things look and work quite right, many things are still too small then and many applications don't follow these settings anyway. The problem for us is that there seems to be no standard system wide DPI setting that can be reliably used. Until there is a standard solution here I guess this will remain something that the user has to configure manually. Brecht. On Sat, Jun 29, 2013 at 2:22 PM, Ton Roosendaal t...@blender.org wrote: Hi, As I explained before, I made MacBook retina to work for HiDPI in the least intrusive way for our code. But I also had to do it in a way it would work for everyone. That meant I had to make two things work independently: - DPI scaling for UIs in general. - Apple's HiDPI implementation Unfortunately these two features were not following an identical specification. That meant I had to seperate it in a Mac-only value (Pixelsize for now) and DPI. For example, a retins dot is default set to be two pixels large. If you start Blender with 72 DPI, it will show visually the same button sizes whether you are in retina mode or not. An important design decision from Apple was to decouple Desktop coordinates from pixels. You can have retina desktops of 1024, 1440, 1920 wide which all get mapped to the actual 2880 screen pixels. But for each desktop width, a dot and standard line widths stay 2 pixels. Still following? :) Mind boggling... especially if you draw the whole UI in OpenGL. I'm still waiting for information how Linux or Windows will address HiDPI. Hopefully in the same way, but probably not... -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] About the location of the Operator panel...
Hi, A good guideline for UI design is to always consider options and choices to be done only in a last unfortunate case when nothing else can work. If you need to patch design to make it usable, we better go back to look at the core design concepts itself. -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 20 Jun, 2013, at 10:40, Gaia wrote: Hi, all; I asked myself: Why does the operator panel appear in the tool shelf although the operator has been called from the properties sidebar ? At least on a large display that can be really far far away :) I have an idea for the case where an operator is called by click on a button from within a Panel: Add a panel option to specify where the operator panel shall show up: - Bottom of Tool Shelf (default) - Bottom of Properties sidebar - Bottom of current window (tool shelf or properties bar, ...) - Directly Below current panel (maybe not a good idea) If the operator was not called from within a panel, then fallback to defaults. Regardless of where it appears, the operator panel disappears when the next operator is called. Benefits: - Operator options can appear very near to where the operator was called, thus get much more awareness - less moving around on large screens to change operator options. Drawbacks: - operator panel no longer appears at one fixed location However letting the operator panel appear close to our current focus of work could possibly be more beneficial than relying on operator options to always appear in the lower left corner of the screen. What do you think about that ? -gaia- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A better way to display the Weight value in weight Paint mode ?
Here are some alternatives which could solve potential problems with custom weight paint colors: http://pasteall.org/pic/show.php?id=54515 What do you think ? (my favorite is now the example in the middle). -gaia- On 29.06.2013 11:32, Ronan Ducluzeau aka zeauro wrote: On 29/06/2013 11:04, Gaia wrote: Hi; I know this breaks every rule of the Blender user interface. However please take a moment (or two) and think about these 2 alternatives for showing the Weight paint value in weight Paint mode: http://pasteall.org/pic/show.php?id=54510 On the left side: the bar changes its color from blue to red depending on the weight value. On the right side: the bar reveals a rainbow while the weight value increases. I think using color here is the most intuitive representation that is possible when working with weight values. And its practical usage ? Well, when i use the weight value then i always think in colors but i have to specify values between 0 and 1. For me this does not match up nicely. The color bar does a better job here imho. I have not made up my mind which of the alternatives works better. Probably the left one, but i am really not sure. -gaia- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Some users can use a custom weight paint gradient from black to white . In this case, RGB color is irrelevant and replacing it by BW could hide weight value. ronan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
Hey Brecht, Note sure if it would help, but on Linux for X dpi, perhaps these options might be of help?: Option UseEdidDpi FALSE Option DPI 96x96 I need them in my xorg.conf here, but in my case, it is because my monitor reports poor info. Anyways, just a side thought since you mentioned. o/ Dan On Sat, Jun 29, 2013 at 9:51 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi, I had a look at this some months ago. For Windows there is a system DPI that you can configure as a user and there's an API to query it. It does not do this OS X trick with the 2x pixel size and decoupled desktop coordinates, all coordinates are in actual pixels. Here's the info: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660(v=vs.85).aspx There might be some unforeseen issues to solve but a Windows developer might be able to get this working quickly with just a few changes in the code. On Linux I don't know what the solution is, I couldn't even get any desktop environment configured to properly work on my MacBook Retina. Typically the advice seems to be to make the fonts bigger, and tweak some settings to make icons bigger, etc. But that alone doesn't make things look and work quite right, many things are still too small then and many applications don't follow these settings anyway. The problem for us is that there seems to be no standard system wide DPI setting that can be reliably used. Until there is a standard solution here I guess this will remain something that the user has to configure manually. Brecht. On Sat, Jun 29, 2013 at 2:22 PM, Ton Roosendaal t...@blender.org wrote: Hi, As I explained before, I made MacBook retina to work for HiDPI in the least intrusive way for our code. But I also had to do it in a way it would work for everyone. That meant I had to make two things work independently: - DPI scaling for UIs in general. - Apple's HiDPI implementation Unfortunately these two features were not following an identical specification. That meant I had to seperate it in a Mac-only value (Pixelsize for now) and DPI. For example, a retins dot is default set to be two pixels large. If you start Blender with 72 DPI, it will show visually the same button sizes whether you are in retina mode or not. An important design decision from Apple was to decouple Desktop coordinates from pixels. You can have retina desktops of 1024, 1440, 1920 wide which all get mapped to the actual 2880 screen pixels. But for each desktop width, a dot and standard line widths stay 2 pixels. Still following? :) Mind boggling... especially if you draw the whole UI in OpenGL. I'm still waiting for information how Linux or Windows will address HiDPI. Hopefully in the same way, but probably not... -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender roadmap article on code blog
Hi, Been busy all week with other stuff, interesting long thread :) Quick observations below: 1) Include opt-in usage and automatic crash reporting in *every* blender build, and a web dashboard to live usage/crash stats to devs and the community. I always wondered what other projects/companies do with such reports. Is there a public example where I can see the handling of such report logging, with evidence for how this is being used well, the benefits? Or is it just for statistics? 2) Increase community leverage, sharing, library asset encapsulation -- more bridges between pro-artists and amateur blender pilots. snip Good ideas, for me that's part of the asset project in our roadmap. 3) Refine and add more end-to-end capabilities. IMO compositing and VFX have a multiplicative not additive effect on Blender's utility. Somehow having merely reasonable integrated 3d+compositing+vfx is better for some tasks than having non-integrated best-of-breed tools for each. snip Lots of this is also just because how things evolved. One by one. Not as part of a grand master plan. Although I agree with the benefits you mention, I'm very wary for the consequences of simply adding it. We have to keep track of (existing) design focus, stability, keeping it manageable, etc. For example: the Sequencer code now can get a full makeover without breaking the rest of Blender. It's highly needed to do that. Solutions for having tracking/compositing/sequencer work together are there too. What I'd like to explore is some kindof image-depsgraph. A user then can manage image dependencies in Blender like: render to image, which gets used as a texture in other render, which goes to compositor, which goes into a VSE, etc etc. 4) Incorporate an extension language which can support Intellisense, type-checking, and fast execution. A big goal is to make scripting easier with Intellisense. Another goal is to enable both new blender additions and old code to be in a solid, typechecked, memory-managed high-level-language. Until recently, I wished for .NET/Mono/C# integration, like some people wished for in Maya before they decided on Python. However, I think there is a new exciting option which is lighter weight and may fit better, and that is TypeScript + Javascript-V8. (Typescript http://www.typescriptlang.org/is a class-based Javascript facade with optional-static typing, and Javascript-V8 is 10-30x fasterhttp://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=alllang=python3lang2=v8data=u64than CPython 3). Obviously this would be done in a way which leverages the investment in Python exports/apis. I can't add much to what has been said in other replies here. I also don't know any of these languages... but to me it seems we're really not doing that bad now. I don't see evidence Python is not satisfying current (technical) users either. - Where Python is too slow (I/O), we can also improve the api a lot still. For our UI now it's more than fast enough. - For Node plugins where speed is crucial (render, compo, future particle, modifiers, etc) we should explore first what already have. OpenCL, OpenShading, LLvm, ... or just a good C/C++ api. -Ton- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
It's not a reliable value to use, because it's not correctly reported by many monitors, and does not actually correspond to the DPI assumed by any other UI toolkit. I've looked for the right value for quite a while, but only conclusion I can find is that none of Gnome/KDE/Xfce/GTK/Qt/.. have proper high DPI support on Linux/X11, it's just not implemented. If one of them did we could copy the same mechanism to detect DPI. On Sat, Jun 29, 2013 at 4:32 PM, Dan McGrath danmcgrath...@gmail.com wrote: Hey Brecht, Note sure if it would help, but on Linux for X dpi, perhaps these options might be of help?: Option UseEdidDpi FALSE Option DPI 96x96 I need them in my xorg.conf here, but in my case, it is because my monitor reports poor info. Anyways, just a side thought since you mentioned. o/ Dan On Sat, Jun 29, 2013 at 9:51 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi, I had a look at this some months ago. For Windows there is a system DPI that you can configure as a user and there's an API to query it. It does not do this OS X trick with the 2x pixel size and decoupled desktop coordinates, all coordinates are in actual pixels. Here's the info: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660(v=vs.85).aspx There might be some unforeseen issues to solve but a Windows developer might be able to get this working quickly with just a few changes in the code. On Linux I don't know what the solution is, I couldn't even get any desktop environment configured to properly work on my MacBook Retina. Typically the advice seems to be to make the fonts bigger, and tweak some settings to make icons bigger, etc. But that alone doesn't make things look and work quite right, many things are still too small then and many applications don't follow these settings anyway. The problem for us is that there seems to be no standard system wide DPI setting that can be reliably used. Until there is a standard solution here I guess this will remain something that the user has to configure manually. Brecht. On Sat, Jun 29, 2013 at 2:22 PM, Ton Roosendaal t...@blender.org wrote: Hi, As I explained before, I made MacBook retina to work for HiDPI in the least intrusive way for our code. But I also had to do it in a way it would work for everyone. That meant I had to make two things work independently: - DPI scaling for UIs in general. - Apple's HiDPI implementation Unfortunately these two features were not following an identical specification. That meant I had to seperate it in a Mac-only value (Pixelsize for now) and DPI. For example, a retins dot is default set to be two pixels large. If you start Blender with 72 DPI, it will show visually the same button sizes whether you are in retina mode or not. An important design decision from Apple was to decouple Desktop coordinates from pixels. You can have retina desktops of 1024, 1440, 1920 wide which all get mapped to the actual 2880 screen pixels. But for each desktop width, a dot and standard line widths stay 2 pixels. Still following? :) Mind boggling... especially if you draw the whole UI in OpenGL. I'm still waiting for information how Linux or Windows will address HiDPI. Hopefully in the same way, but probably not... -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
I think there are at least three topics worth discussing here.. (a) how should blender appear on a hidpi display, relative to a regular display (either dual monitor, or when moving a blend file between machines) (b) how should the Blender code achieve this.. (c) how is hidpi detected on different systems. first (a)... how should blender appear on hidpi? On Sat, Jun 29, 2013 at 5:22 AM, Ton Roosendaal t...@blender.org wrote: ...it will show visually the same button sizes whether you are in retina mode or not. I think this is the right behavior. Also, when a users has blender visible on both retina and non-retina displays, those UI should appear the same size. This requires HiDPI support to use something like the per-surface pixelsize instead of the the user-preference dpi setting... so the current strategy makes sense in that regard. (though the user-preference might be better named ui-scaling, since it really isn't strictly dpi) now (b)...how should the code achieve this?... Today there are bugs in this hidpi/pixelsize behavior, and I believe this is in large part because of how exposed dpi/pixelsize are to drawing/input code. For example, node-editor and uv-editor do not appear the same size on retina and non-retina at the same local-zoom, because the current zoom is not translated for pixelsize. This seems to be the source of another retina bug, where adding a node using the context menu causes it to appear at the wrong place on hidpi. Ton - Do you have any long-term opposition to the code encapsulating pixelsize (hidpi) and dpi (aka ui scaling) issues at a lower-level -- by introducing a virtual coordinate system for blender, much like apple has a virtual coordinate system? This would require changes to 2d drawing code, as well as 3d view projection setup functions.. but as a benefit would free (most) other code from dealing with DPI / pixelsize. I don't know enough to attempt this change now, and it may not be the right time to do it, since it would make ui-code merges more difficult. However, I would like to know what you think about it. In the short-term, it may be easier to fix both the uv-editor and node-editor to use the current pattern and properly use pixelsize / DPI to appear the same on retina and non-retina. finally (c)...how is hidpi detected on different systems, and different monitors on the same system On Mac, the system gives you the pixelsize for a display surface, and it seems to magically deal with windows spanning multiple surfaces, by telling you one surface DPI and automatically scaling the content for the other display. On Linux, there are multiple ways to achieve multi-monitor. Last time I looked, the most common method was using a dual-headed graphics card with a super big coordinate space that looks like a single big monitor. I don't think this can support heterogeneous normal/hi-dpi. Xinerama might be able to. AFAIK, Windows still hasn't fully figured out their HiDPI API strategy. I suspect a hetrogenius normal/hi-dpi setup in windows would be problematic today... ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
On Saturday, June 29, 2013 04:47:09 PM Brecht Van Lommel wrote: It's not a reliable value to use, because it's not correctly reported by many monitors, and does not actually correspond to the DPI assumed by any other UI toolkit. I've looked for the right value for quite a while, but only conclusion I can find is that none of Gnome/KDE/Xfce/GTK/Qt/.. have proper high DPI support on Linux/X11, it's just not implemented. If one of them did we could copy the same mechanism to detect DPI. Blog post from yesterday may provide insight into how others are tackling the issue. http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome/ -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A better way to display the Weight value in weight Paint mode ?
I think that the best place to show weight color of brush is probably brush circle, itself. Do you think it is possible to have an overlay feature for that in Weight Paint mode ? Weight Paint Mode is the only one to have no overlay feature. Sculpt, Texture and Vertex Paint modes are sharing the same Overlay color. -ronan- On 29/06/2013 16:10, Gaia wrote: Here are some alternatives which could solve potential problems with custom weight paint colors: http://pasteall.org/pic/show.php?id=54515 What do you think ? (my favorite is now the example in the middle). -gaia- On 29.06.2013 11:32, Ronan Ducluzeau aka zeauro wrote: On 29/06/2013 11:04, Gaia wrote: Hi; I know this breaks every rule of the Blender user interface. However please take a moment (or two) and think about these 2 alternatives for showing the Weight paint value in weight Paint mode: http://pasteall.org/pic/show.php?id=54510 On the left side: the bar changes its color from blue to red depending on the weight value. On the right side: the bar reveals a rainbow while the weight value increases. I think using color here is the most intuitive representation that is possible when working with weight values. And its practical usage ? Well, when i use the weight value then i always think in colors but i have to specify values between 0 and 1. For me this does not match up nicely. The color bar does a better job here imho. I have not made up my mind which of the alternatives works better. Probably the left one, but i am really not sure. -gaia- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Some users can use a custom weight paint gradient from black to white . In this case, RGB color is irrelevant and replacing it by BW could hide weight value. ronan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
Hi, (a) how should blender appear on a hidpi display, relative to a regular display (either dual monitor, or when moving a blend file between machines) That's supported and working already even! (b) how should the Blender code achieve this.. Given the fact every pixel in our UI is opengl code, it's inevitable that there's local conversions needed for UI items in views. In general this goes it very nice - when code itself is nice and using opengl correctly - and messy in parts only when hardcoded values are used. The remainder bugs for HiDPI are mainly because hardly anyone is using it yet :) Each reported issue is really an easy fix. For image drawing... we can check on it. I just wasn't sure if you want to have zoom level 1 defined as 2 pixels for image pixels... that would be annoying I think. When 4k arrives on the desktop (during next years) we can figure out better. My experience with 4k production however is that you really want to see images as 1 pixel = 1 display pixel. Not an easy fix in Blender is when 2d view transforms (like nodes) are used together with UI widget drawing. I kept this open, knowing node UI future is a todo item in general. Ton - Do you have any long-term opposition to the code encapsulating pixelsize (hidpi) and dpi (aka ui scaling) issues at a lower-level -- by introducing a virtual coordinate system for blender, much like apple has a virtual coordinate system? Apple achieves HiDPI only via their own widget and Cocoa APIs. I think Blender is the first of non-Cocoa apps in Mac supporting this even. We could do this thanks to OpenGL, which is already using coordinate systems for all UI items. This is also why the DPI features works so well, and why you can zoom in/out for UI elements. When 4k systems arrive on desktops for other OSes, they probably would just keep 1 desktop pixel to stay 1 display pixel. For these situations we can simply allow a user to set pixel size to 2, so you get nice lines and 'dot' units and buttons draw accordingly. We don't need to use the desktop coordinate system mapping from Apple then. -Ton- (c) how is hidpi detected on different systems. first (a)... how should blender appear on hidpi? On Sat, Jun 29, 2013 at 5:22 AM, Ton Roosendaal t...@blender.org wrote: ...it will show visually the same button sizes whether you are in retina mode or not. I think this is the right behavior. Also, when a users has blender visible on both retina and non-retina displays, those UI should appear the same size. This requires HiDPI support to use something like the per-surface pixelsize instead of the the user-preference dpi setting... so the current strategy makes sense in that regard. (though the user-preference might be better named ui-scaling, since it really isn't strictly dpi) now (b)...how should the code achieve this?... Today there are bugs in this hidpi/pixelsize behavior, and I believe this is in large part because of how exposed dpi/pixelsize are to drawing/input code. For example, node-editor and uv-editor do not appear the same size on retina and non-retina at the same local-zoom, because the current zoom is not translated for pixelsize. This seems to be the source of another retina bug, where adding a node using the context menu causes it to appear at the wrong place on hidpi. Ton - Do you have any long-term opposition to the code encapsulating pixelsize (hidpi) and dpi (aka ui scaling) issues at a lower-level -- by introducing a virtual coordinate system for blender, much like apple has a virtual coordinate system? This would require changes to 2d drawing code, as well as 3d view projection setup functions.. but as a benefit would free (most) other code from dealing with DPI / pixelsize. I don't know enough to attempt this change now, and it may not be the right time to do it, since it would make ui-code merges more difficult. However, I would like to know what you think about it. In the short-term, it may be easier to fix both the uv-editor and node-editor to use the current pattern and properly use pixelsize / DPI to appear the same on retina and non-retina. finally (c)...how is hidpi detected on different systems, and different monitors on the same system On Mac, the system gives you the pixelsize for a display surface, and it seems to magically deal with windows spanning multiple surfaces, by telling you one surface DPI and automatically scaling the content for the other display. On Linux, there are multiple ways to achieve multi-monitor. Last time I looked, the most common method was using a dual-headed graphics card with a super big coordinate space that looks like a single big monitor. I don't think this can support heterogeneous normal/hi-dpi. Xinerama might be able to. AFAIK, Windows still hasn't fully figured out their HiDPI API strategy. I suspect a hetrogenius normal/hi-dpi setup in windows would be problematic today...
Re: [Bf-committers] A better way to display the Weight value in weight Paint mode ?
Enabling overlay, even texture access for weight painting is not too hard. I can probably add it after release. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A better way to display the Weight value in weight Paint mode ?
Finally, I am not sure if overlay is needed. There is already radial control to set weight of brush. Maybe it is possible just to color what is already there. http://www.pasteall.org/pic/show.php?id=54536 But as gaia said; there is a keymap conflict when we use a rigged model. W keymap for radial control in Weight Paint is used by Specials menu in Pose Mode. http://www.pasteall.org/pic/show.php?id=54537 Keymap for radial control could be changed to something else like K. There is also two other keymap conflicts. A : Select All/ Stroke Method Shift F : Flip Select Active Bone/ radial control for Strength If Flip Select Active Bone can easily be reassigned to Ctrl F; it is more difficult to find another keymap for Stroke Method. -ronan- On 29/06/2013 18:53, Antony Riakiotakis wrote: Enabling overlay, even texture access for weight painting is not too hard. I can probably add it after release. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A better way to display the Weight value in weight Paint mode ?
It would be probably better to display only one color. http://www.pasteall.org/pic/show.php?id=54544 -ronan- On 29/06/2013 18:53, Antony Riakiotakis wrote: Enabling overlay, even texture access for weight painting is not too hard. I can probably add it after release. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A better way to display the Weight value in weight Paint mode ?
From a purely UX point of view the multicolor mockups are better even though they may look worse in the UI. It shows you without having to play with the widget exactly where you need to be at a glance. The other one is an improvement over the current solution, but not as nice overall. I guess it depends on the goal. Are we looking to A) Make a widget that does not intrude too much on overall look of the UI, yet gives more functionality than exists currently or B) Make a widget that gives a lot of info at a glance, but is very helpful to power users, but that might not look great when taken in context of overall UI? -Sean On Sat, Jun 29, 2013 at 3:00 PM, Ronan Ducluzeau aka zeauro zeau...@gmail.com wrote: It would be probably better to display only one color. http://www.pasteall.org/pic/show.php?id=54544 -ronan- On 29/06/2013 18:53, Antony Riakiotakis wrote: Enabling overlay, even texture access for weight painting is not too hard. I can probably add it after release. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- ||-- Instant Messengers -- || ICQ at 11133295 || AIM at shatterstar98 || MSN Messenger at shatte...@hotmail.com || Yahoo Y! at the_7th_samuri ||-- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
Looking away from the details for a moment.. It would be helpful to have a clear Blender HiDPI philosophy, so we know the right way to fix these bugs... I'll take a shot at this now... If I understand your philosophy Ton, I think it is: 1) Editors where 2d pixels are not edited (everything except the uv-editor), should appear to be at the same zoom-level/origin when loaded on normal and high dpi displays. This means that a single blend file loaded on normal and high dpi would have 3dviews and node-editors positioned and zoomed to show roughly the same amount of stuff. Can we agree on #1? For image drawing... we can check on it. I just wasn't sure if you want to have zoom level 1 defined as 2 pixels for image pixels... that would be annoying I think. Here is a second guidline to explain this... 2) Editors where 2d pixels can be directly edited (today just the uv-editor), should keep their data-to-screen-pixel ratio constant when loaded on normal and high dpi display. This means a uv-editor setup zoomed to take up most of the screen on high-dpi, would be 2-4x the screen size when loaded on normal dpi. My sensibilities say to drop #2 and make everything #1. However, I'm not an artist who paints on 2d uv-maps. It would be good to hear their opinion here. If #2 rule stays, it would be useful to know if this applies to scenerios where the uv-editor is used a results display, such as render/compositor results -- or only 2d image editing. We might also consider these possible guidelines: optional 3) Views showing 2d pixels have an obvious way to get to 1:1 mapping, and an obvious visual that they are in 1:1 mapping. optional 4) Views showing 2d pixels have zoom steps and/or snaps to make integer mappins easy to arrive at. I like #3 more than #4, though I can see arguments for each. After we get through the philosophy, we can apply it to the details Not an easy fix in Blender is when 2d view transforms (like nodes) are used together with UI widget drawing. I kept this open, knowing node UI future is a todo item in general. I see two related bugs in the node-editor which seem easy to fix, and I would like to fix... but I don't know the agreed way to fix them without the above HiDPI Philosophy. :) A) Node-editor shift-a node placement not aligned to mouse on Retina... http://projects.blender.org/tracker/index.php?func=detailaid=35920group_id=9atid=498 B) Node-editor content in a blend is zoomed different on retina vs normal... (this is a bug if we agree on HiDPI Philosophy point #1 above) Fixing B should automatically fix A. However, if B is not a bug, then the screen-to-nodespace coordinate transform for new node creation must be changed to adjust for pixelsize. This is in python and AFAIK python does not have access to pixelsize currently. Given the fact every pixel in our UI is opengl code, it's inevitable that there's local conversions needed for UI items in views. In general this goes it very nice - when code itself is nice and using opengl correctly - and messy in parts only when hardcoded values are used. The remainder bugs for HiDPI are mainly because hardly anyone is using it yet :) Each reported issue is really an easy fix. I agree that today the easiest solution to fix the node-editor bugs above is by adding a pixelsize adjustment in the right place, and I plan to do it myself. It is also easy to manually fix other similar bugs, and teach every future blender UI coder to properly use DPI and pixelsize in their screen-to-editor transforms. However, in continuing to choose the short term easy route, we are creating needless complexity, where unncessary amounts of code have to deal with DPI and pixelsize. I don't believe there is anything inevitable about having all drawing code know about DPI and pixelsize. OSX Cocoa APIs pretty successfully hide these details from all code that doesn't care about them by using a virtual coordinate space. AFAIK, it's an easy but larger refactor to abstract DPI and pixelsize behind drawing and drawing-setup abstractions -- freeign future programmers from having to think about it. Rather than debating what is possible though, perhaps I can rephrase this as a more practical question When might be a good time to consider such a large-but-easy refactor patch, given GSOC branch merging and other such things? I'd personally like to make this patch and show how it would work, but there is no hurry, as it's going to be a while before I understand blender code enough anyhow. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender roadmap article on code blog
On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal t...@blender.org wrote: 1) Include opt-in usage and automatic crash reporting in *every* blender build, and a web dashboard to live usage/crash stats to devs and the community. I always wondered what other projects/companies do with such reports. Is there a public example where I can see the handling of such report logging, with evidence for how this is being used well, the benefits? Or is it just for statistics? I'm not aware of anyone who publishes information about how much their own software crashes, this would probably be very hard to manage PR on. I will say that at the large well known companies I've worked for, we tracked and graphed usage, error, and performance stats for nearly-all server-side and most client side software (opt-in on the client side). When the graphs all look good they are not used much, but when odd things start happening, the graphs are often the only way to know something is going wrong. It also helps avoid bad priorities, because the data is more statistically relevant than one person telling you XYZ when there are thousands or millions of users. As for the detailed crash dumps, and stack backtraces.. The utility of these is very related to how much correlation there is between the stack and the actual bug. Parasitic memory-stomp bugs can't be found with these reports. However, many other types of bugs become quite obvious by correlating the stacks and looking at a few user-written descriptions. I have more personal experience with this for server-side than client-side, but then I have been more involved with server-side than client-side development. The real kicker is, IMO, usage, crash, and performance reporting has more value for the application than ANY other similar amount of feature work -- because it tracks activity of all code. Reliability and Performance are two of software's most important features, so it is very useful to pay attention to them. Solutions for having tracking/compositing/sequencer work together are there too. What I'd like to explore is some kindof image-depsgraph. A user then can manage image dependencies in Blender like: render to image, which gets used as a texture in other render, which goes to compositor, which goes into a VSE, etc etc. That's an excellent vision. It feels very much like blender as an art build pipeline. AFAIK, big shops setup that kind of stuff with builds and scripts. Doing it inside blender could have a bunch of great advantages (a) interactivity, (b) easier sharing, (c) more accessible to artists who are not programmers... among others.. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender roadmap article on code blog
Campbell Barton wrote theres not much incentive to rewrite - only for the sake of cleaner code. I totally understand and wouldn't argue they should be, never touch a working system and all that. Having the TODO make pep 8 compliant comment in the header is also a good hint that they are perhaps not the best inspiration for new code. Campbell Barton wrote Afraid every time I try do something non-trivial in someone else's open-source project (non-blender), its pretty steep learning curve too, getting from some template/example code to something useful is just tricky and theres so much assumed knowledge about how components work together, what kind of patterns your expected to use etc... ...clip... For functions local to a file they often aren't commented much. I can see why you might like comments here but I would leave this up to the author of each script to choose how much to comment internal functions, classes etc - rather then defining a policy As you note, one of the hardest parts of getting your head around a complex, unfamiliar, code base is figuring out all the unstated assumptions about component interactions and design patterns. The only way I can do that is by diving in to the existing production code. Having the API documented is great but it is no substitute for being able to see how people intimately familiar with it are using it. Sure I can work out what is going on by reading the code, but having consumer functions that are using the API well document goes a long way towards flattening out the learning curve. David Jeske wrote On Fri, Jun 28, 2013 at 1:35 PM, Knapp lt; magick.crow@ gt; wrote: I think it would be nice to see a typed scripting option How about Python Traits? Note I have no idea how difficult it would be to use Traits as a wrapper for Blender's API, although Enthought does provide a Traits based wrapper for VTK so I'm sure it would be possible. -- View this message in context: http://blender.45788.x6.nabble.com/Blender-roadmap-article-on-code-blog-tp109587p110358.html Sent from the Bf-committers mailing list archive at Nabble.com. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] About the location of the Operator panel...
On Jun 29, 2013 7:01 AM, Ton Roosendaal t...@blender.org wrote: If you need to patch design to make it usable, we better go back to look at the core design concepts itself. While the 3 current operator UIs (menu-bar modal text, tools-opperator panel, and F6 floating panel) are usable.. they don't seem to be part of any core design concept. They don't even have the same visual style, so they appear unrealted to each-other for the untrained user. I saw one ultra-simple blenderartists proposal to merely make them visually consistent, by simply standardizing on the F6-floating-panel color-theme (white text on the black background) for all 3. Please forgive my super-bad mockup... I couldn't find the better looking original mockup. I hope you get the idea... http://www.pasteall.org/pic/54578 A slightly larger change, which I personally like, also from blender artists, is to combine the F6 panel and tools-operator-panel into one thing In the lower right of 3dview. It would normally show collapsed with only the current/last operator title. Clicking on it, or pressing F6, would toggle it open, providing the full operator edit UI. Again, I couldn't find the original mockups, so I made these really bad ones... please forgive the bad quality... http://www.pasteall.org/pic/54573 http://www.pasteall.org/pic/54574 In the case of trigger-buttons like Gaia's property panel button case, or add-on UI like for cell-fracture http://www.pasteall.org/pic/54579, the panel could open floating next to the button press and retire to the lower-right corner after the user stopped interacting with it. I plan to eventually generate a patch to the second one just to see how it feels. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender roadmap article on code blog
When I fix bugs in unfamiliar projects, I spend 90% of my time getting it to build and playing sherlock holmes tracking down weak-linkages like dynamic-typed variables and weak-linkages (like strings used as enums in C) -- and 10% of my time actually trying to understand or fix code. In strong typed code (C, C++, C#, TypeScript, etc) and a modern IDE (Visual Studio or one of its many clones), that 90% shrinks dramatically, as I can see, understand, and explore the types of variables immediately. I hover-over a variable in the IDE it shows the type. I hit goto declaration it takes me to the type-declaration. No project wide grep or guessing at the type of that dynamic-typed a paramater. How about Python Traits? Note I have no idea how difficult it would be to use Traits as a wrapper for Blender's API, although Enthought does provide a Traits based wrapper for VTK so I'm sure it would be possible. I'm not very familiar with Traits, but from a quick look it appears to be a run-time assignment validation and format coercion package. It does not appear to contain any compiled time variable type information, or the ability to do type-aware code-navigation or completion. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Community leverage, asset encapsulation (was: Blender Roadmap)
On Tue, Jun 25, 2013 at 7:19 AM, Campbell Barton ideasma...@gmail.comwrote: 2) Increase community leverage, sharing, library asset encapsulation -- more bridges between pro-artists and amateur blender pilots. Material-sharing is being figured out. I'd like to be able to enapsulate a more complex parameterized block into something with external easy to use push-buttons... +1 Any thoughts on how we might make this work? Here are some brainstorm thoughts about these two strawman goals.. (a) let [a user] group/encapsulate/re-use/share a 10 node color-keying setup with an external mask-input, key-color-input, and exposed internal RGB curve editor used for foreground feather color correction; A first question is... does this concept of exposing internal node parameter UI for specific fields, while hiding other internal nodes, enable an interesting set of reusable compositing node-groups? What might specific examples be? foreground object chrome key with color correction ~ 7 nodes vignetting ~4 nodes ...? (b) let me wrap up the (scene, model, logic, animation, script, and render setup) for a 3d rendered and composited video-title-effect which can be used directly from the video-sequence-editor with simple animatable fields like color, title text, font, position. This seems like it needs some way to hide scene parts, so the scene becomes locked and opaque from the outside, except for a set of easy to use parameters -- which would be shown as easy to use things in the VSE. The scene(s) might even be hidden from the scene list unless the VSE user pushes the edit button to customize their internals. Any other community sharing ideas? Another one on my list is a bit simpler and related to asset sharing.. (c) create metadata to link the purpose of assets based on compatibility, and use that meta to make it easier to browse, pick, and load relevant pieces for a currently active object. For example, if I want to load alternate textures for a wagon model my local or a public asset library, it would be useful to see only textures which have been mapped to fit the wagon model. Likewise for shape keys, poses, etc.. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender roadmap article on code blog
I think that you've hit upon two of the important factors here: - familiarity - discoverability To which I would also add - refactorability (is that a word? :-) Those familiar with a project might not see the value in strong typing simply because it doesn't add much to their personal experience. They have less need to explore types, usage locations, etc., because they're already familiar with them. However, strong typing does add an additional level of confidence when re-factoring, which can even benefit those who are intimately familiar with a code base. Anecdotally, you hear about this from people who have had to re-factor Python... things like You really come to appreciate your test suite when refactoring, etc. The reliance on test suites arising because many compile-time checks are impossible with dynamically-typed languages. Jonathan Merritt. On Sun, Jun 30, 2013 at 1:13 PM, David Jeske dav...@gmail.com wrote: When I fix bugs in unfamiliar projects, I spend 90% of my time getting it to build and playing sherlock holmes tracking down weak-linkages like dynamic-typed variables and weak-linkages (like strings used as enums in C) -- and 10% of my time actually trying to understand or fix code. In strong typed code (C, C++, C#, TypeScript, etc) and a modern IDE (Visual Studio or one of its many clones), that 90% shrinks dramatically, as I can see, understand, and explore the types of variables immediately. I hover-over a variable in the IDE it shows the type. I hit goto declaration it takes me to the type-declaration. No project wide grep or guessing at the type of that dynamic-typed a paramater. How about Python Traits? Note I have no idea how difficult it would be to use Traits as a wrapper for Blender's API, although Enthought does provide a Traits based wrapper for VTK so I'm sure it would be possible. I'm not very familiar with Traits, but from a quick look it appears to be a run-time assignment validation and format coercion package. It does not appear to contain any compiled time variable type information, or the ability to do type-aware code-navigation or completion. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
