Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Tomasz Wlostowski]

On 12/01/2022 14:24, pmx wrote:


Le 12/01/2022 à 13:32, Franck Bourdonnec a écrit :


well, my second laptop is a an old e525 acer that is more than enough 
rapid to do 'internet/video/kicad/kicad debuging...' even with 2~3 
hours for a full build.

Having it unable to run KiCad , very disapointing ;)



Funny enough (so to speak...), my main laptop mainboard just crashed and 
I'm currently back to a 2007 Hewlett-Packard laptop (15 years old!) 
running Linux.
The Nvidia GPU driver is not supported anymore by the latest X11  
(AFAIK, they dropped the DirectX9 programming interface. Have to use 
Nouveau driver + DRI / OpenGL2.1).

.
Surprisingly, I can run Freecad almost flawlessly (on not too 
complicated designs), but Eeschema is stunningly slow (for example, 
serious lag when moving components onscreen).
A positive note : a slow machine help put some parts of the code 
efficiency under the magnifying glass  !!


Do you have antialiasing enabled?





Don't partitipate to "obsolescence programmée" ("programmed trashing 
?") ?


-> AFAIK, This is "Planned Obsolescence".


Well, if someone planned it, it's not us, but Apple and MS. Under Linux 
you can at least use any version of KiCad you please (or you're free to 
hack the newest master to your needs).


Tom



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[pmx]

Le 12/01/2022 à 13:32, Franck Bourdonnec a écrit :


well, my second laptop is a an old e525 acer that is more than enough 
rapid to do 'internet/video/kicad/kicad debuging...' even with 2~3 
hours for a full build.

Having it unable to run KiCad , very disapointing ;)



Funny enough (so to speak...), my main laptop mainboard just crashed and 
I'm currently back to a 2007 Hewlett-Packard laptop (15 years old!) 
running Linux.
The Nvidia GPU driver is not supported anymore by the latest X11  
(AFAIK, they dropped the DirectX9 programming interface. Have to use 
Nouveau driver + DRI / OpenGL2.1).

.
Surprisingly, I can run Freecad almost flawlessly (on not too 
complicated designs), but Eeschema is stunningly slow (for example, 
serious lag when moving components onscreen).
A positive note : a slow machine help put some parts of the code 
efficiency under the magnifying glass  !!




Don't partitipate to "obsolescence programmée" ("programmed trashing 
?") ?


-> AFAIK, This is "Planned Obsolescence".


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Franck Bourdonnec]

2012 : what a travel in time !

well, my second laptop is a an old e525 acer that is more than enough 
rapid to do 'internet/video/kicad/kicad debuging...' even with 2~3 hours 
for a full build.

Having it unable to run KiCad , very disapointing ;)

The other one is not much younger.

Don't partitipate to "obsolescence programmée" ("programmed trashing ?") ?


Le 12/01/2022 à 13:22, pmx a écrit :



Le 11/01/2022 à 22:57, Tomasz Wlostowski a écrit :
There's a LOT of room for improvement just by using more modern GPU 
features (and by modern I mean from 2012). 


2012 : what a travel in time !

Tomasz, thanks for the explanations.

BTW, I only worked on the schematics, this summer (for some private 
assessment of a few schematics features or UI improvements), that's why 
my remark was so inaccurate.


Pierre.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

!DSPAM:61dec8657009223232303!





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[pmx]

Le 11/01/2022 à 22:57, Tomasz Wlostowski a écrit :
There's a LOT of room for improvement just by using more modern GPU 
features (and by modern I mean from 2012). 


2012 : what a travel in time !

Tomasz, thanks for the explanations.

BTW, I only worked on the schematics, this summer (for some private 
assessment of a few schematics features or UI improvements), that's why 
my remark was so inaccurate.


Pierre.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Tomasz Wlostowski]

On 11/01/2022 22:45, pmx wrote:


 From my previous tests (Kicad 5.99), I can say that any speed 
bottleneck is likely NOT in the rendering engine, but in the rest of the 
code.
I can't count how many Boost:: containers are scanned, and even 
temporarily created and deleted, when you play with the graphics 
elements in the schematics !

(The 3D viewer is a different matter).


Dear pmx,

The biggest performance hog is zone fill rendering and triangulation 
which unfortunately has to be done on the CPU because (mostly for Linux 
and older Intel chipset users) we use a very old OpenGL 2.1 version.


Also lack of geometry shaders causes a huge PCI bandwidth overhead (each 
track segment is 2 triangles + attributes, sent from the CPU).


There's a LOT of room for improvement just by using more modern GPU 
features (and by modern I mean from 2012).


Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Jon Evans]

> Do you intend to support an new backend on  MacOS and Windows only, and
keep the current OpenGL backend on Linux (can't see a good reason for this)
?

No, if we switched to some abstraction layer such as bgfx, we'd use that on
all platforms.  That layer may then end up using OpenGL as _its_ backend.

> can say that any speed bottleneck is likely NOT in the rendering engine,
but in the rest of the code.

There are certain situations (that don't impact the majority of current
KiCad users) where the rendering engine is indeed a bottleneck in the PCB
editor and Gerber viewer.  As we try to make KiCad applicable to more
high-end designers, it could become an issue for more people.

-Jon

On Tue, Jan 11, 2022 at 4:46 PM pmx  wrote:

>
>
> Le 11/01/2022 à 21:59, Jon Evans a écrit :
>
> The current offerings (e.g. bgfx) are generally multi-platform but without
> the software fallback option.
>
>
> OK, got it.
>
> I just had a look at bgfx, seems neat.
>
> BTW, the bgfx::Init() fuction seems to accept a
> BGFX_PCI_ID_SOFTWARE_RASTERIZER parameter, may be the trick (or not...)
>
> Now, I totally agree that there is no point to develop/support a private,
> updated, fallback rendering engine from scratch in the future.
>
>
>
> Yes, OpenGL will likely remain supported on systems other than Windows/Mac
> for now at least, but we at some point will have to decide if we want to
> bump our minimum OpenGL version to something higher than 2.1.
>
>
> Do you intend to support an new backend on  MacOS and Windows only, and
> keep the current OpenGL backend on Linux (can't see a good reason for this)
> ?
> If it were me, I wouldn't touch the current rendering code (i.e. like
> switching to OpenGL 4.x), and devote all the future effort toward the
> integration of the new graphics backend on all platforms.
>
> From my previous tests (Kicad 5.99), I can say that any speed bottleneck
> is likely NOT in the rendering engine, but in the rest of the code.
> I can't count how many Boost:: containers are scanned, and even
> temporarily created and deleted, when you play with the graphics elements
> in the schematics !
> (The 3D viewer is a different matter).
>
> Pierre.
>
>
>
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[pmx]

Le 11/01/2022 à 21:59, Jon Evans a écrit :
The current offerings (e.g. bgfx) are generally multi-platform but 
without the software fallback option.


OK, got it.

I just had a look at bgfx, seems neat.

BTW, the |bgfx|::|||Init()| fuction seems to accept a 
|BGFX_PCI_ID_SOFTWARE_RASTERIZER| parameter, may be the trick (or not...)


Now, I totally agree that there is no point to develop/support a 
private, updated, fallback rendering engine from scratch in the future.





Yes, OpenGL will likely remain supported on systems other than 
Windows/Mac for now at least, but we at some point will have to decide 
if we want to bump our minimum OpenGL version to something higher than 
2.1.




Do you intend to support an new backend on  MacOS and Windows only, and 
keep the current OpenGL backend on Linux (can't see a good reason for 
this) ?
If it were me, I wouldn't touch the current rendering code (i.e. like 
switching to OpenGL 4.x), and devote all the future effort toward the 
integration of the new graphics backend on all platforms.


From my previous tests (Kicad 5.99), I can say that any speed 
bottleneck is likely NOT in the rendering engine, but in the rest of the 
code.
I can't count how many Boost:: containers are scanned, and even 
temporarily created and deleted, when you play with the graphics 
elements in the schematics !

(The 3D viewer is a different matter).

Pierre.





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Steven A. Falco]

On 1/11/22 04:02 PM, Seth Hillbrand wrote:



On Tue, Jan 11, 2022 at 12:48 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

On 1/11/22 03:24 PM, Seth Hillbrand wrote:
 > We will not directly disable running in a VM.
 >
 > Our stance is that if there are issues running KiCad in a VM, they 
should be reported to the maker of the VM, not KiCad.

I'm going to have to disagree with that stance a little, Seth.  The initial bug 
report https://gitlab.com/kicad/code/kicad/-/issues/8944 
 was from a Virtualbox user. 
 Then I saw the problem using the native Linux KVM.  Two different VM 
implementations.  And I think the root cause was a KiCad bug where the code didn't 
properly test for GLX_EXT_swap_control_tear.  So reporting to either of those VM 
makers would not have been effective, in this case.


Root cause was Mesa/X11 reporting that it was able to handle a call to 
GLX_EXT_swap_control_tear.  And then crashing when that call was made.

The "fix" was to test for a Mesa driver and then prevent it from calling the 
adaptive sync.

I stand by the statement that this is a bug in other programs (in this case, 
the Mesa driver used by the VM softwares.

KiCad can work around this issue (and all of the other fallback issues as 
well).  But then, that is where developer time goes instead of into developing 
new schematic and layout features that will be of use to our whole userbase.

This is why we will not be focussing on supporting VMs or fallback graphics in 
the future.


I stand corrected.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Seth Hillbrand]

On Tue, Jan 11, 2022 at 12:48 PM Steven A. Falco 
wrote:

> On 1/11/22 03:24 PM, Seth Hillbrand wrote:
> > We will not directly disable running in a VM.
> >
> > Our stance is that if there are issues running KiCad in a VM, they
> should be reported to the maker of the VM, not KiCad.
>
> I'm going to have to disagree with that stance a little, Seth.  The
> initial bug report https://gitlab.com/kicad/code/kicad/-/issues/8944 was
> from a Virtualbox user.  Then I saw the problem using the native Linux
> KVM.  Two different VM implementations.  And I think the root cause was a
> KiCad bug where the code didn't properly test for
> GLX_EXT_swap_control_tear.  So reporting to either of those VM makers would
> not have been effective, in this case.
>

Root cause was Mesa/X11 reporting that it was able to handle a call to
GLX_EXT_swap_control_tear.  And then crashing when that call was made.

The "fix" was to test for a Mesa driver and then prevent it from calling
the adaptive sync.

I stand by the statement that this is a bug in other programs (in this
case, the Mesa driver used by the VM softwares.

KiCad can work around this issue (and all of the other fallback issues as
well).  But then, that is where developer time goes instead of into
developing new schematic and layout features that will be of use to our
whole userbase.

This is why we will not be focussing on supporting VMs or fallback graphics
in the future.

Seth



-- 
[image: KiCad Services Corporation Logo]
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬
Long Beach, CA
www.kipro-pcb.comi...@kipro-pcb.com
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Jon Evans]

The current offerings (e.g. bgfx) are generally multi-platform but without
the software fallback option.

Yes, OpenGL will likely remain supported on systems other than Windows/Mac
for now at least, but we at some point will have to decide if we want to
bump our minimum OpenGL version to something higher than 2.1.

On Tue, Jan 11, 2022 at 3:57 PM pmx  wrote:

>
>
> Le 11/01/2022 à 21:10, Jon Evans a écrit :
> > > IMHO, we shouldn't remove anything that helps to deal gracefully
> > with the diversity of situations (like a virtual machine), graphics
> > hardware and video drivers... and their possible bugs ! (as stated
> > about X11/Mesa).
> > [...]
> > we need to push forward into more modern hardware-accelerated graphics
> > APIs in order to make it possible to implement some desirable
> > features, help performance on large designs, etc.
> >
> > The idea is that instead of being stuck on some "lowest common
> > denominator" OpenGL, we can instead for example use DirectX on Windows
> > and Metal on macOS.
> >
> > -Jon
> >
>
> It would be nice, then, to choose a modern backend that supports
> natively multiple hardware engine, including a pure software rendering
> that could be used as "fallback". Slower, but may save the day to some.
>
>
> These third party graphics layers are usually multi platform/OS, and a
> software only rendering option is reasonable expectation, but I really
> don't know what is the current "offer", in 2021.
>
>
> Anyway, taking this into account from the beginning could make it happen
> with very little development overhead later.
>
>
> (BTW, OpenGL may well still be the hidden engine for Unix-like systems -
> just my guess).
>
> Pierre.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[pmx]

Le 11/01/2022 à 21:10, Jon Evans a écrit :
> IMHO, we shouldn't remove anything that helps to deal gracefully 
with the diversity of situations (like a virtual machine), graphics 
hardware and video drivers... and their possible bugs ! (as stated 
about X11/Mesa).

[...]
we need to push forward into more modern hardware-accelerated graphics 
APIs in order to make it possible to implement some desirable 
features, help performance on large designs, etc.


The idea is that instead of being stuck on some "lowest common 
denominator" OpenGL, we can instead for example use DirectX on Windows 
and Metal on macOS.


-Jon



It would be nice, then, to choose a modern backend that supports 
natively multiple hardware engine, including a pure software rendering 
that could be used as "fallback". Slower, but may save the day to some.



These third party graphics layers are usually multi platform/OS, and a 
software only rendering option is reasonable expectation, but I really 
don't know what is the current "offer", in 2021.



Anyway, taking this into account from the beginning could make it happen 
with very little development overhead later.



(BTW, OpenGL may well still be the hidden engine for Unix-like systems - 
just my guess).


Pierre.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Steven A. Falco]

On 1/11/22 03:24 PM, Seth Hillbrand wrote:

We will not directly disable running in a VM.

Our stance is that if there are issues running KiCad in a VM, they should be 
reported to the maker of the VM, not KiCad.


I'm going to have to disagree with that stance a little, Seth.  The initial bug 
report https://gitlab.com/kicad/code/kicad/-/issues/8944 was from a Virtualbox 
user.  Then I saw the problem using the native Linux KVM.  Two different VM 
implementations.  And I think the root cause was a KiCad bug where the code 
didn't properly test for GLX_EXT_swap_control_tear.  So reporting to either of 
those VM makers would not have been effective, in this case.

Regardless, I'm glad you won't be disabling VM support because I need KiCad to 
work in a VM.  That is the only way I can test the official Fedora releases 
that I build.  Specifically, I'll first try my builds out in an F34 VM, a 
Rawhide VM, etc. before unleashing them on the community.

I don't have multiple physical machines running all those different Fedora 
editions, let alone Ubuntu and some others that I occasionally test with, so if 
I lose VM capability, I'll lose the ability to test what I build.

Steve



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Seth Hillbrand]

We will not directly disable running in a VM.

Our stance is that if there are issues running KiCad in a VM, they should
be reported to the maker of the VM, not KiCad.

Seth

On Tue, Jan 11, 2022 at 12:22 PM Mark Robson  wrote:

> I use Kicad in a Linux VM, and it sort of works ok, it's really convenient.
>
> Obviously there are limits with software rendering, the 3d viewer is slow
> but otherwise it's ok.
>
> Mark
>
> On Tue, 11 Jan 2022 at 20:11, Jon Evans  wrote:
>
>> > IMHO, we shouldn't remove anything that helps to deal gracefully with
>> the diversity of situations (like a virtual machine), graphics hardware and
>> video drivers... and their possible bugs ! (as stated about X11/Mesa).
>>
>> The fallback engine we use today does not have feature-parity with the
>> accelerated engine, and that is not an easily-solvable problem.
>> Continuing to support it will continue to hold us back.
>>
>> Putting aside the issue of virtual machines (our stance is that we don't
>> need to spend effort on supporting VMs because KiCad itself should run fine
>> on the host OS), we need to push forward into more modern
>> hardware-accelerated graphics APIs in order to make it possible to
>> implement some desirable features, help performance on large designs, etc.
>>
>> The idea is that instead of being stuck on some "lowest common
>> denominator" OpenGL, we can instead for example use DirectX on Windows and
>> Metal on macOS.
>>
>> -Jon
>>
>> On Tue, Jan 11, 2022 at 3:02 PM Steven A. Falco 
>> wrote:
>>
>>> On 1/11/22 02:33 PM, pmx wrote:
>>> >
>>> >
>>> > Le 11/01/2022 à 19:25, Steven A. Falco a écrit :
>>> >>> I don't think the dialog would help any in the situation you are
>>> describing with the artifacts on the screen. It was only shown on first
>>> start, so it wouldn't give the choice in future runs (which would be after
>>> you notice all the artifacts). You can change the rendering backend in the
>>> preferences pane though, so you can switch back to the fallback graphics
>>> that way.
>>> >>
>>> >> I'm describing two situations.  One is the artifacts on my desktop,
>>> and one is the segfault on VMs.  As long as the window opens and is
>>> somewhat usable, then one can select fallback graphics easily from
>>> preferences, as you said.  The bigger problem is on the VMs where it
>>> crashes before the window gets a chance to even open.  I'll look at the
>>> issue you linked and see if that helps.  I'll also try a test build from
>>> the tip of the 6.0 branch and see how that behaves.
>>> >>
>>> >> I'm more concerned that fallback graphics might be removed entirely
>>> at some point.  Hopefully accelerated mode will be bullet-proof before that
>>> decision is made.
>>> >>
>>> >> Steve
>>> >
>>> > Unless there is much work involved to keep both backends working in
>>> the future, I strongly feel that a fallback graphics engine is a must and
>>> should be kept alive, even if this requires some (moderate...) effort.
>>> >
>>> > IMHO, we shouldn't remove anything that helps to deal gracefully with
>>> the diversity of situations (like a virtual machine), graphics hardware and
>>> video drivers... and their possible bugs ! (as stated about X11/Mesa).
>>> >
>>> >
>>> > @ Steven :
>>> > About the possibility to choose a graphics backend, in any situation,
>>> and indeed before a segfault  happens  :
>>> >
>>> > What about a command line option (when launching Kicad), to force a
>>> specific graphics backend, including a "safe" fallback ?
>>> > Should be quite straightforward.
>>>
>>> The segfault is fixed in the latest 6.0 code, so I guess there is no
>>> longer a need for either the dialog or a command.
>>>
>>> However, some of the visual artifacts are still happening even with the
>>> latest 6.0 code, therefore the fallback graphics mode is still essential.
>>>
>>> I've added another video showing what it looks like when I resize the
>>> pcbnew screen.  Please see comment
>>> https://gitlab.com/kicad/code/kicad/-/issues/10375#note_807446302 and
>>> https://gitlab.com/kicad/code/kicad/uploads/0aed9475350c1665d0cc200187536121/simplescreenrecorder-2022-01-11_14.29.16.mkv
>>> for details.
>>>
>>> I'm a little concerned that new users seeing these artifacts won't know
>>> what to do about them, and may give up.
>>>
>>> Steve
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to 

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Mark Robson]

I use Kicad in a Linux VM, and it sort of works ok, it's really convenient.

Obviously there are limits with software rendering, the 3d viewer is slow
but otherwise it's ok.

Mark

On Tue, 11 Jan 2022 at 20:11, Jon Evans  wrote:

> > IMHO, we shouldn't remove anything that helps to deal gracefully with
> the diversity of situations (like a virtual machine), graphics hardware and
> video drivers... and their possible bugs ! (as stated about X11/Mesa).
>
> The fallback engine we use today does not have feature-parity with the
> accelerated engine, and that is not an easily-solvable problem.
> Continuing to support it will continue to hold us back.
>
> Putting aside the issue of virtual machines (our stance is that we don't
> need to spend effort on supporting VMs because KiCad itself should run fine
> on the host OS), we need to push forward into more modern
> hardware-accelerated graphics APIs in order to make it possible to
> implement some desirable features, help performance on large designs, etc.
>
> The idea is that instead of being stuck on some "lowest common
> denominator" OpenGL, we can instead for example use DirectX on Windows and
> Metal on macOS.
>
> -Jon
>
> On Tue, Jan 11, 2022 at 3:02 PM Steven A. Falco 
> wrote:
>
>> On 1/11/22 02:33 PM, pmx wrote:
>> >
>> >
>> > Le 11/01/2022 à 19:25, Steven A. Falco a écrit :
>> >>> I don't think the dialog would help any in the situation you are
>> describing with the artifacts on the screen. It was only shown on first
>> start, so it wouldn't give the choice in future runs (which would be after
>> you notice all the artifacts). You can change the rendering backend in the
>> preferences pane though, so you can switch back to the fallback graphics
>> that way.
>> >>
>> >> I'm describing two situations.  One is the artifacts on my desktop,
>> and one is the segfault on VMs.  As long as the window opens and is
>> somewhat usable, then one can select fallback graphics easily from
>> preferences, as you said.  The bigger problem is on the VMs where it
>> crashes before the window gets a chance to even open.  I'll look at the
>> issue you linked and see if that helps.  I'll also try a test build from
>> the tip of the 6.0 branch and see how that behaves.
>> >>
>> >> I'm more concerned that fallback graphics might be removed entirely at
>> some point.  Hopefully accelerated mode will be bullet-proof before that
>> decision is made.
>> >>
>> >> Steve
>> >
>> > Unless there is much work involved to keep both backends working in the
>> future, I strongly feel that a fallback graphics engine is a must and
>> should be kept alive, even if this requires some (moderate...) effort.
>> >
>> > IMHO, we shouldn't remove anything that helps to deal gracefully with
>> the diversity of situations (like a virtual machine), graphics hardware and
>> video drivers... and their possible bugs ! (as stated about X11/Mesa).
>> >
>> >
>> > @ Steven :
>> > About the possibility to choose a graphics backend, in any situation,
>> and indeed before a segfault  happens  :
>> >
>> > What about a command line option (when launching Kicad), to force a
>> specific graphics backend, including a "safe" fallback ?
>> > Should be quite straightforward.
>>
>> The segfault is fixed in the latest 6.0 code, so I guess there is no
>> longer a need for either the dialog or a command.
>>
>> However, some of the visual artifacts are still happening even with the
>> latest 6.0 code, therefore the fallback graphics mode is still essential.
>>
>> I've added another video showing what it looks like when I resize the
>> pcbnew screen.  Please see comment
>> https://gitlab.com/kicad/code/kicad/-/issues/10375#note_807446302 and
>> https://gitlab.com/kicad/code/kicad/uploads/0aed9475350c1665d0cc200187536121/simplescreenrecorder-2022-01-11_14.29.16.mkv
>> for details.
>>
>> I'm a little concerned that new users seeing these artifacts won't know
>> what to do about them, and may give up.
>>
>> Steve
>>
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Jon Evans]

> IMHO, we shouldn't remove anything that helps to deal gracefully with the
diversity of situations (like a virtual machine), graphics hardware and
video drivers... and their possible bugs ! (as stated about X11/Mesa).

The fallback engine we use today does not have feature-parity with the
accelerated engine, and that is not an easily-solvable problem.
Continuing to support it will continue to hold us back.

Putting aside the issue of virtual machines (our stance is that we don't
need to spend effort on supporting VMs because KiCad itself should run fine
on the host OS), we need to push forward into more modern
hardware-accelerated graphics APIs in order to make it possible to
implement some desirable features, help performance on large designs, etc.

The idea is that instead of being stuck on some "lowest common denominator"
OpenGL, we can instead for example use DirectX on Windows and Metal on
macOS.

-Jon

On Tue, Jan 11, 2022 at 3:02 PM Steven A. Falco 
wrote:

> On 1/11/22 02:33 PM, pmx wrote:
> >
> >
> > Le 11/01/2022 à 19:25, Steven A. Falco a écrit :
> >>> I don't think the dialog would help any in the situation you are
> describing with the artifacts on the screen. It was only shown on first
> start, so it wouldn't give the choice in future runs (which would be after
> you notice all the artifacts). You can change the rendering backend in the
> preferences pane though, so you can switch back to the fallback graphics
> that way.
> >>
> >> I'm describing two situations.  One is the artifacts on my desktop, and
> one is the segfault on VMs.  As long as the window opens and is somewhat
> usable, then one can select fallback graphics easily from preferences, as
> you said.  The bigger problem is on the VMs where it crashes before the
> window gets a chance to even open.  I'll look at the issue you linked and
> see if that helps.  I'll also try a test build from the tip of the 6.0
> branch and see how that behaves.
> >>
> >> I'm more concerned that fallback graphics might be removed entirely at
> some point.  Hopefully accelerated mode will be bullet-proof before that
> decision is made.
> >>
> >> Steve
> >
> > Unless there is much work involved to keep both backends working in the
> future, I strongly feel that a fallback graphics engine is a must and
> should be kept alive, even if this requires some (moderate...) effort.
> >
> > IMHO, we shouldn't remove anything that helps to deal gracefully with
> the diversity of situations (like a virtual machine), graphics hardware and
> video drivers... and their possible bugs ! (as stated about X11/Mesa).
> >
> >
> > @ Steven :
> > About the possibility to choose a graphics backend, in any situation,
> and indeed before a segfault  happens  :
> >
> > What about a command line option (when launching Kicad), to force a
> specific graphics backend, including a "safe" fallback ?
> > Should be quite straightforward.
>
> The segfault is fixed in the latest 6.0 code, so I guess there is no
> longer a need for either the dialog or a command.
>
> However, some of the visual artifacts are still happening even with the
> latest 6.0 code, therefore the fallback graphics mode is still essential.
>
> I've added another video showing what it looks like when I resize the
> pcbnew screen.  Please see comment
> https://gitlab.com/kicad/code/kicad/-/issues/10375#note_807446302 and
> https://gitlab.com/kicad/code/kicad/uploads/0aed9475350c1665d0cc200187536121/simplescreenrecorder-2022-01-11_14.29.16.mkv
> for details.
>
> I'm a little concerned that new users seeing these artifacts won't know
> what to do about them, and may give up.
>
> Steve
>
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Steven A. Falco]

On 1/11/22 02:33 PM, pmx wrote:



Le 11/01/2022 à 19:25, Steven A. Falco a écrit :

I don't think the dialog would help any in the situation you are describing 
with the artifacts on the screen. It was only shown on first start, so it 
wouldn't give the choice in future runs (which would be after you notice all 
the artifacts). You can change the rendering backend in the preferences pane 
though, so you can switch back to the fallback graphics that way.


I'm describing two situations.  One is the artifacts on my desktop, and one is 
the segfault on VMs.  As long as the window opens and is somewhat usable, then 
one can select fallback graphics easily from preferences, as you said.  The 
bigger problem is on the VMs where it crashes before the window gets a chance 
to even open.  I'll look at the issue you linked and see if that helps.  I'll 
also try a test build from the tip of the 6.0 branch and see how that behaves.

I'm more concerned that fallback graphics might be removed entirely at some 
point.  Hopefully accelerated mode will be bullet-proof before that decision is 
made.

Steve 


Unless there is much work involved to keep both backends working in the future, 
I strongly feel that a fallback graphics engine is a must and should be kept 
alive, even if this requires some (moderate...) effort.

IMHO, we shouldn't remove anything that helps to deal gracefully with the 
diversity of situations (like a virtual machine), graphics hardware and video 
drivers... and their possible bugs ! (as stated about X11/Mesa).


@ Steven :
About the possibility to choose a graphics backend, in any situation, and 
indeed before a segfault  happens  :

What about a command line option (when launching Kicad), to force a specific graphics 
backend, including a "safe" fallback ?
Should be quite straightforward.


The segfault is fixed in the latest 6.0 code, so I guess there is no longer a 
need for either the dialog or a command.

However, some of the visual artifacts are still happening even with the latest 
6.0 code, therefore the fallback graphics mode is still essential.

I've added another video showing what it looks like when I resize the pcbnew 
screen.  Please see comment 
https://gitlab.com/kicad/code/kicad/-/issues/10375#note_807446302 and 
https://gitlab.com/kicad/code/kicad/uploads/0aed9475350c1665d0cc200187536121/simplescreenrecorder-2022-01-11_14.29.16.mkv
 for details.

I'm a little concerned that new users seeing these artifacts won't know what to 
do about them, and may give up.

Steve





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[pmx]

Le 11/01/2022 à 19:25, Steven A. Falco a écrit :
I don't think the dialog would help any in the situation you are 
describing with the artifacts on the screen. It was only shown on 
first start, so it wouldn't give the choice in future runs (which 
would be after you notice all the artifacts). You can change the 
rendering backend in the preferences pane though, so you can switch 
back to the fallback graphics that way.


I'm describing two situations.  One is the artifacts on my desktop, 
and one is the segfault on VMs.  As long as the window opens and is 
somewhat usable, then one can select fallback graphics easily from 
preferences, as you said.  The bigger problem is on the VMs where it 
crashes before the window gets a chance to even open.  I'll look at 
the issue you linked and see if that helps.  I'll also try a test 
build from the tip of the 6.0 branch and see how that behaves.


I'm more concerned that fallback graphics might be removed entirely at 
some point.  Hopefully accelerated mode will be bullet-proof before 
that decision is made.


Steve 


Unless there is much work involved to keep both backends working in the 
future, I strongly feel that a fallback graphics engine is a must and 
should be kept alive, even if this requires some (moderate...) effort.


IMHO, we shouldn't remove anything that helps to deal gracefully with 
the diversity of situations (like a virtual machine), graphics hardware 
and video drivers... and their possible bugs ! (as stated about X11/Mesa).



@ Steven :
About the possibility to choose a graphics backend, in any situation, 
and indeed before a segfault  happens  :


What about a command line option (when launching Kicad), to force a 
specific graphics backend, including a "safe" fallback ?

Should be quite straightforward.


Cheers,
pmx.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Steven A. Falco]

On 1/11/22 12:31 PM, Ian McInerney wrote:

Hi Steve,

On Tue, Jan 11, 2022 at 3:47 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

I've opened https://gitlab.com/kicad/code/kicad/-/issues/10375 


I'll be adding more info to the issue as I do more testing.  Right now, the 
issue just reports on visual artifacts that make accelerated graphics unusable 
on my desktop machine.

I'll add info on the segfaults that I see in VMs asap.


This might already have been reported in 
https://gitlab.com/kicad/code/kicad/-/issues/8944 
 and fixed in the master and 
6.0 branches. There is a workaround in there for v6 that you could try (it is setting 
an environment variable before launching KiCad).


I'll do that - thanks for the pointer.


This stuff will no doubt take time to resolve.  The artifacts may be even 
harder to address than the segfaults, because I don't see how to gather data on 
what is causing the flickering and pad color errors as described in the issue.  
I therefore respectfully recommend putting the dialog back in until the issues 
are resolved.


I don't think the dialog would help any in the situation you are describing 
with the artifacts on the screen. It was only shown on first start, so it 
wouldn't give the choice in future runs (which would be after you notice all 
the artifacts). You can change the rendering backend in the preferences pane 
though, so you can switch back to the fallback graphics that way.


I'm describing two situations.  One is the artifacts on my desktop, and one is 
the segfault on VMs.  As long as the window opens and is somewhat usable, then 
one can select fallback graphics easily from preferences, as you said.  The 
bigger problem is on the VMs where it crashes before the window gets a chance 
to even open.  I'll look at the issue you linked and see if that helps.  I'll 
also try a test build from the tip of the 6.0 branch and see how that behaves.

I'm more concerned that fallback graphics might be removed entirely at some 
point.  Hopefully accelerated mode will be bullet-proof before that decision is 
made.

Steve



-Ian

         Steve

On 1/11/22 09:03 AM, Seth Hillbrand wrote:
 > Hi Steve-
 >
 > Please open an issue with the details of your machines that crash when 
trying to use accelerated graphics.  We thought that we had addressed all or 
almost all of these cases.
 >
 > Our current plan is to shift our backend graphics away from the 
OpenGL/Cairo engines and use a third-party library like libbgfx.  This may remove 
any option for Cairo rendering in the future, so it'll be good to work out the 
kinks.
 >
 > And for the peanut gallery: of course we check libraries and query 
features before using them.  The segfaults happen when libraries return values 
that they don't actually support.  Mesa/X11 is a big culprit here on Linux and 
older bulit-in intel drivers on Windows do the same.  The way we do better is to 
get detailed system reports when segfaults happen.  If folks just sit on these 
issues because fallback works for them, then we'll never fix them.
 >
 > Seth
 >
 > On Mon, Jan 10, 2022 at 8:55 PM Steven A. Falco mailto:stevenfa...@gmail.com> >> wrote:
 >
 >     In the past, when running eeschema or pcbnew for the first time, it 
would ask if I wanted to try accelerated graphics.  That no longer seems to be the 
case - I don't get that dialog.
 >
 >     I don't know if the dialog was intentionally removed or if it is a 
bug, but I think it is an issue either way, because the default is now accelerated 
graphics, which results in segfaults on some machines that I have here.
 >
 >     Today I was trying some experiments in a new VM, and I couldn't 
launch eeschema, either from the main app or standalone.  It would segfault before 
putting up its window.  Then I remembered that I had had that problem in the past 
when I was trying out accelerated graphics.  But in the past, I was able to select 
fallback graphics from that initial dialog.
 >
 >     In this case, my only way to fix the situation was to copy the json 
config files from another machine that was already configured for fallback 
graphics.  That worked.  KiCad was now usable in the VM.
 >
 >     Most people won't have a set of suitable json files laying around to 
get past the segfault, or even know to try that.  Thus, I think the initial dialog 
needs to be there, or perhaps the default should be changed to fallback graphics.
 >
 >              Steve
 >
 >     ___
 >     Mailing list: https://launchpad.net/~kicad-developers 
 

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Ian McInerney]

Hi Steve,

On Tue, Jan 11, 2022 at 3:47 PM Steven A. Falco 
wrote:

> I've opened https://gitlab.com/kicad/code/kicad/-/issues/10375
>
> I'll be adding more info to the issue as I do more testing.  Right now,
> the issue just reports on visual artifacts that make accelerated graphics
> unusable on my desktop machine.
>
> I'll add info on the segfaults that I see in VMs asap.
>

This might already have been reported in
https://gitlab.com/kicad/code/kicad/-/issues/8944 and fixed in the master
and 6.0 branches. There is a workaround in there for v6 that you could try
(it is setting an environment variable before launching KiCad).


> This stuff will no doubt take time to resolve.  The artifacts may be even
> harder to address than the segfaults, because I don't see how to gather
> data on what is causing the flickering and pad color errors as described in
> the issue.  I therefore respectfully recommend putting the dialog back in
> until the issues are resolved.
>
>
I don't think the dialog would help any in the situation you are describing
with the artifacts on the screen. It was only shown on first start, so it
wouldn't give the choice in future runs (which would be after you notice
all the artifacts). You can change the rendering backend in the preferences
pane though, so you can switch back to the fallback graphics that way.

-Ian


> Steve
>
> On 1/11/22 09:03 AM, Seth Hillbrand wrote:
> > Hi Steve-
> >
> > Please open an issue with the details of your machines that crash when
> trying to use accelerated graphics.  We thought that we had addressed all
> or almost all of these cases.
> >
> > Our current plan is to shift our backend graphics away from the
> OpenGL/Cairo engines and use a third-party library like libbgfx.  This may
> remove any option for Cairo rendering in the future, so it'll be good to
> work out the kinks.
> >
> > And for the peanut gallery: of course we check libraries and query
> features before using them.  The segfaults happen when libraries return
> values that they don't actually support.  Mesa/X11 is a big culprit here on
> Linux and older bulit-in intel drivers on Windows do the same.  The way we
> do better is to get detailed system reports when segfaults happen.  If
> folks just sit on these issues because fallback works for them, then we'll
> never fix them.
> >
> > Seth
> >
> > On Mon, Jan 10, 2022 at 8:55 PM Steven A. Falco  > wrote:
> >
> > In the past, when running eeschema or pcbnew for the first time, it
> would ask if I wanted to try accelerated graphics.  That no longer seems to
> be the case - I don't get that dialog.
> >
> > I don't know if the dialog was intentionally removed or if it is a
> bug, but I think it is an issue either way, because the default is now
> accelerated graphics, which results in segfaults on some machines that I
> have here.
> >
> > Today I was trying some experiments in a new VM, and I couldn't
> launch eeschema, either from the main app or standalone.  It would segfault
> before putting up its window.  Then I remembered that I had had that
> problem in the past when I was trying out accelerated graphics.  But in the
> past, I was able to select fallback graphics from that initial dialog.
> >
> > In this case, my only way to fix the situation was to copy the json
> config files from another machine that was already configured for fallback
> graphics.  That worked.  KiCad was now usable in the VM.
> >
> > Most people won't have a set of suitable json files laying around to
> get past the segfault, or even know to try that.  Thus, I think the initial
> dialog needs to be there, or perhaps the default should be changed to
> fallback graphics.
> >
> >  Steve
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp <
> https://help.launchpad.net/ListHelp>
> >
> >
> >
> > --
> > KiCad Services Corporation Logo
> > Seth Hillbrand
> > *Lead Developer*
> > +1-530-302-5483‬
> > Long Beach, CA
> > www.kipro-pcb.com  i...@kipro-pcb.com
> 
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Steven A. Falco]

I've opened https://gitlab.com/kicad/code/kicad/-/issues/10375

I'll be adding more info to the issue as I do more testing.  Right now, the 
issue just reports on visual artifacts that make accelerated graphics unusable 
on my desktop machine.

I'll add info on the segfaults that I see in VMs asap.

This stuff will no doubt take time to resolve.  The artifacts may be even 
harder to address than the segfaults, because I don't see how to gather data on 
what is causing the flickering and pad color errors as described in the issue.  
I therefore respectfully recommend putting the dialog back in until the issues 
are resolved.

Steve

On 1/11/22 09:03 AM, Seth Hillbrand wrote:

Hi Steve-

Please open an issue with the details of your machines that crash when trying 
to use accelerated graphics.  We thought that we had addressed all or almost 
all of these cases.

Our current plan is to shift our backend graphics away from the OpenGL/Cairo 
engines and use a third-party library like libbgfx.  This may remove any option 
for Cairo rendering in the future, so it'll be good to work out the kinks.

And for the peanut gallery: of course we check libraries and query features 
before using them.  The segfaults happen when libraries return values that they 
don't actually support.  Mesa/X11 is a big culprit here on Linux and older 
bulit-in intel drivers on Windows do the same.  The way we do better is to get 
detailed system reports when segfaults happen.  If folks just sit on these 
issues because fallback works for them, then we'll never fix them.

Seth

On Mon, Jan 10, 2022 at 8:55 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

In the past, when running eeschema or pcbnew for the first time, it would 
ask if I wanted to try accelerated graphics.  That no longer seems to be the 
case - I don't get that dialog.

I don't know if the dialog was intentionally removed or if it is a bug, but 
I think it is an issue either way, because the default is now accelerated 
graphics, which results in segfaults on some machines that I have here.

Today I was trying some experiments in a new VM, and I couldn't launch 
eeschema, either from the main app or standalone.  It would segfault before 
putting up its window.  Then I remembered that I had had that problem in the 
past when I was trying out accelerated graphics.  But in the past, I was able 
to select fallback graphics from that initial dialog.

In this case, my only way to fix the situation was to copy the json config 
files from another machine that was already configured for fallback graphics.  
That worked.  KiCad was now usable in the VM.

Most people won't have a set of suitable json files laying around to get 
past the segfault, or even know to try that.  Thus, I think the initial dialog 
needs to be there, or perhaps the default should be changed to fallback 
graphics.

         Steve

___
Mailing list: https://launchpad.net/~kicad-developers 

Post to     : kicad-developers@lists.launchpad.net 

Unsubscribe : https://launchpad.net/~kicad-developers 

More help   : https://help.launchpad.net/ListHelp 




--
KiCad Services Corporation Logo
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬
Long Beach, CA
www.kipro-pcb.com  i...@kipro-pcb.com 





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Seth Hillbrand]

Hi Steve-

Please open an issue with the details of your machines that crash when
trying to use accelerated graphics.  We thought that we had addressed all
or almost all of these cases.

Our current plan is to shift our backend graphics away from the
OpenGL/Cairo engines and use a third-party library like libbgfx.  This may
remove any option for Cairo rendering in the future, so it'll be good to
work out the kinks.

And for the peanut gallery: of course we check libraries and query features
before using them.  The segfaults happen when libraries return values that
they don't actually support.  Mesa/X11 is a big culprit here on Linux and
older bulit-in intel drivers on Windows do the same.  The way we do better
is to get detailed system reports when segfaults happen.  If folks just sit
on these issues because fallback works for them, then we'll never fix them.

Seth

On Mon, Jan 10, 2022 at 8:55 PM Steven A. Falco 
wrote:

> In the past, when running eeschema or pcbnew for the first time, it would
> ask if I wanted to try accelerated graphics.  That no longer seems to be
> the case - I don't get that dialog.
>
> I don't know if the dialog was intentionally removed or if it is a bug,
> but I think it is an issue either way, because the default is now
> accelerated graphics, which results in segfaults on some machines that I
> have here.
>
> Today I was trying some experiments in a new VM, and I couldn't launch
> eeschema, either from the main app or standalone.  It would segfault before
> putting up its window.  Then I remembered that I had had that problem in
> the past when I was trying out accelerated graphics.  But in the past, I
> was able to select fallback graphics from that initial dialog.
>
> In this case, my only way to fix the situation was to copy the json config
> files from another machine that was already configured for fallback
> graphics.  That worked.  KiCad was now usable in the VM.
>
> Most people won't have a set of suitable json files laying around to get
> past the segfault, or even know to try that.  Thus, I think the initial
> dialog needs to be there, or perhaps the default should be changed to
> fallback graphics.
>
> Steve
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


-- 
[image: KiCad Services Corporation Logo]
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬
Long Beach, CA
www.kipro-pcb.comi...@kipro-pcb.com
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Brian]



From the peanut gallery:

I have a hard time swallowing the idea that there’s no way to determine whether 
accelerated graphics will work at runtime short of a seg fault.  Granted, 
3rd-party bugs are always possible, but KiCAD should be able to check for 
libraries and features in order to successfully drop back to fallback graphics 
without seg faulting on anything but a truly broken system.  

All that to say it shouldn’t be necessary to default to fallback if we can do a 
better job at startup of determining whether accelerated graphics will work.

$0.02,
-Brian

> On Jan 10, 2022, at 11:55 PM, Steven A. Falco  wrote:
> In the past, when running eeschema or pcbnew for the first time, it would 
> ask if I wanted to try accelerated graphics.  That no longer seems to be the 
> case - I don't get that dialog.
> 
> I don't know if the dialog was intentionally removed or if it is a bug, but I 
> think it is an issue either way, because the default is now accelerated 
> graphics, which results in segfaults on some machines that I have here.
> 
> Today I was trying some experiments in a new VM, and I couldn't launch 
> eeschema, either from the main app or standalone.  It would segfault before 
> putting up its window.  Then I remembered that I had had that problem in the 
> past when I was trying out accelerated graphics.  But in the past, I was able 
> to select fallback graphics from that initial dialog.
> 
> In this case, my only way to fix the situation was to copy the json config 
> files from another machine that was already configured for fallback graphics. 
>  That worked.  KiCad was now usable in the VM.
> 
> Most people won't have a set of suitable json files laying around to get past 
> the segfault, or even know to try that.  Thus, I think the initial dialog 
> needs to be there, or perhaps the default should be changed to fallback 
> graphics.
> 
>Steve
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp