From pbergeron at spiria.com Fri Aug 3 09:52:22 2018 From: pbergeron at spiria.com (Patrick Bergeron) Date: Fri, 3 Aug 2018 13:52:22 +0000 Subject: [vtk-developers] Any of you guys going to siggraph 2018 in vancouver? Message-ID: Just wondering. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Aug 3 13:16:36 2018 From: sean at rogue-research.com (Sean McBride) Date: Fri, 3 Aug 2018 13:16:36 -0400 Subject: [vtk-developers] Apple deprecates OpenGL in macOS 10.14 In-Reply-To: References: <20180605231514.639830101@mail.rogue-research.com> <20180611212108.1080467667@mail.rogue-research.com> Message-ID: <20180803171636.1051974844@mail.rogue-research.com> I filed a bug with Apple for the 'vtkRenderingCorePython-rotations' test failure, and it seems to be fixed in 10.14 beta 5. Sean On Tue, 12 Jun 2018 09:24:00 -0400, Ken Martin said: >everything but the timeout looks suspicious to me. > >On Mon, Jun 11, 2018 at 5:21 PM, Sean McBride >wrote: > >> Hi all, >> >> I updated my Rogue12 bot from macOS 10.9 to 10.14 beta. >> >> It's not too bad: >> >> >> >> >> Do any of those look like (OpenGL) bugs I should file with Apple? From utkarsh.ayachit at kitware.com Tue Aug 7 10:29:31 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 7 Aug 2018 10:29:31 -0400 Subject: [vtk-developers] Support for logging Message-ID: Folks, Of late I've been finding myself needing some sort of logging support when debugging complex issues in ParaView and the more I thought about it, the more I realized it should really be in VTK too and hence this email. I wonder what folks thought about adding support for generating logs to VTK. This goes beyond the vtkTimerLog we currently have. vtkTimerLog is great to log filter execution times etc. but it lacks features like levels of verbosity, among others that are needed in a general purpose logging infrastructure. We could potentially make vtkTImerLog use the chosen logging infrastructure under the covers, but that's a separate discussion and not entirely relevant to the topic at hand. To illustrate a case where this is useful in VTK: has anyone ever tried to debug why a filter is re-executing? One often ends up in the weeds of vtkExecutive and subclass and is fraught with frustration. Now, imagine that the vtkExecutive subclass just generated a log indicate which pipeline pass it's executing, and why -- things would be so easy! The log could be added only at higher levels of verbosity, thus not pollute application logs with internal details, but would be easily generate-able/accessible when needed. Same is true for rendering pipelines, determining if the VBOs, for example, are being regenerated and why can be easily logged and aid tracking down performance issues. If we are convinced of the need for a logging support, then the question becomes which logging library to use? I have been using for loguru[1] with great success for a multi-threaded app. I love it's output generation style, plus how well it handles logs from multiple threads. It's C++ friendly, header only, minimal external dependencies. Thoughts? Suggestions? Utkarsh [1] https://github.com/emilk/loguru From wascott at sandia.gov Tue Aug 7 12:38:06 2018 From: wascott at sandia.gov (Scott, W Alan) Date: Tue, 7 Aug 2018 16:38:06 +0000 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: Message-ID: <1533659887385.2809@sandia.gov> Great idea. For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable. Alan ________________________________________ From: vtk-developers on behalf of Utkarsh Ayachit Sent: Tuesday, August 7, 2018 8:29 AM To: vtk-developers at vtk.org Subject: [EXTERNAL] [vtk-developers] Support for logging Folks, Of late I've been finding myself needing some sort of logging support when debugging complex issues in ParaView and the more I thought about it, the more I realized it should really be in VTK too and hence this email. I wonder what folks thought about adding support for generating logs to VTK. This goes beyond the vtkTimerLog we currently have. vtkTimerLog is great to log filter execution times etc. but it lacks features like levels of verbosity, among others that are needed in a general purpose logging infrastructure. We could potentially make vtkTImerLog use the chosen logging infrastructure under the covers, but that's a separate discussion and not entirely relevant to the topic at hand. To illustrate a case where this is useful in VTK: has anyone ever tried to debug why a filter is re-executing? One often ends up in the weeds of vtkExecutive and subclass and is fraught with frustration. Now, imagine that the vtkExecutive subclass just generated a log indicate which pipeline pass it's executing, and why -- things would be so easy! The log could be added only at higher levels of verbosity, thus not pollute application logs with internal details, but would be easily generate-able/accessible when needed. Same is true for rendering pipelines, determining if the VBOs, for example, are being regenerated and why can be easily logged and aid tracking down performance issues. If we are convinced of the need for a logging support, then the question becomes which logging library to use? I have been using for loguru[1] with great success for a multi-threaded app. I love it's output generation style, plus how well it handles logs from multiple threads. It's C++ friendly, header only, minimal external dependencies. Thoughts? Suggestions? Utkarsh [1] https://github.com/emilk/loguru _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers From lasso at queensu.ca Tue Aug 7 13:03:40 2018 From: lasso at queensu.ca (Andras Lasso) Date: Tue, 7 Aug 2018 17:03:40 +0000 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: <1533659887385.2809@sandia.gov> References: , <1533659887385.2809@sandia.gov> Message-ID: <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated? Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity. Andras ________________________________ From: "Scott, W Alan via vtk-developers" Sent: Tuesday, August 7, 2018 6:38 PM To: Ayachit, Utkarsh (External Contacts); vtk-developers at vtk.org Subject: Re: [vtk-developers] [EXTERNAL] Support for logging Great idea. For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable. Alan ________________________________________ From: vtk-developers on behalf of Utkarsh Ayachit Sent: Tuesday, August 7, 2018 8:29 AM To: vtk-developers at vtk.org Subject: [EXTERNAL] [vtk-developers] Support for logging Folks, Of late I've been finding myself needing some sort of logging support when debugging complex issues in ParaView and the more I thought about it, the more I realized it should really be in VTK too and hence this email. I wonder what folks thought about adding support for generating logs to VTK. This goes beyond the vtkTimerLog we currently have. vtkTimerLog is great to log filter execution times etc. but it lacks features like levels of verbosity, among others that are needed in a general purpose logging infrastructure. We could potentially make vtkTImerLog use the chosen logging infrastructure under the covers, but that's a separate discussion and not entirely relevant to the topic at hand. To illustrate a case where this is useful in VTK: has anyone ever tried to debug why a filter is re-executing? One often ends up in the weeds of vtkExecutive and subclass and is fraught with frustration. Now, imagine that the vtkExecutive subclass just generated a log indicate which pipeline pass it's executing, and why -- things would be so easy! The log could be added only at higher levels of verbosity, thus not pollute application logs with internal details, but would be easily generate-able/accessible when needed. Same is true for rendering pipelines, determining if the VBOs, for example, are being regenerated and why can be easily logged and aid tracking down performance issues. If we are convinced of the need for a logging support, then the question becomes which logging library to use? I have been using for loguru[1] with great success for a multi-threaded app. I love it's output generation style, plus how well it handles logs from multiple threads. It's C++ friendly, header only, minimal external dependencies. Thoughts? Suggestions? Utkarsh [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&reserved=0 _______________________________________________ Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 Follow this link to subscribe/unsubscribe: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 _______________________________________________ Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 Follow this link to subscribe/unsubscribe: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From allison.vacanti at kitware.com Tue Aug 7 13:25:21 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Tue, 7 Aug 2018 13:25:21 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: +1. The loguru outputs I've seen are very nice. I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic. On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso wrote: > VTK has already a logging API that sends messages to stdout/stderr by > default but it can be easily configured to send messages to any logging > system. Do you mean you would keep the current logging API and just change > the default logging backend to something more sophisticated? > > Somewhat related issue: For me, it has never been completely clear how VTK > debug logs could be used in practice, as most often it is very difficult to > set DebugOn for an object (or group of relevant objects). It would be > probably better to enable logging by default for all objects and split > current debug level to 3 levels (info/debug/trace) for better control of > verbosity. > > Andras > ------------------------------ > *From:* "Scott, W Alan via vtk-developers" kitware.com> > *Sent:* Tuesday, August 7, 2018 6:38 PM > *To:* Ayachit, Utkarsh (External Contacts); vtk-developers at vtk.org > *Subject:* Re: [vtk-developers] [EXTERNAL] Support for logging > > Great idea. For someone that doesn't know where to place breakpoints, but > has to try to debug datasets that cannot be sent to Kitware, this would be > incredibly valuable. > > Alan > > ________________________________________ > From: vtk-developers on > behalf of Utkarsh Ayachit > Sent: Tuesday, August 7, 2018 8:29 AM > To: vtk-developers at vtk.org > Subject: [EXTERNAL] [vtk-developers] Support for logging > > Folks, > > Of late I've been finding myself needing some sort of logging support > when debugging complex issues in ParaView and the more I thought about > it, the more I realized it should really be in VTK too and hence this > email. > > I wonder what folks thought about adding support for generating logs > to VTK. This goes beyond the vtkTimerLog we currently have. > vtkTimerLog is great to log filter execution times etc. but it lacks > features like levels of verbosity, among others that are needed in a > general purpose logging infrastructure. We could potentially make > vtkTImerLog use the chosen logging infrastructure under the covers, > but that's a separate discussion and not entirely relevant to the > topic at hand. > > To illustrate a case where this is useful in VTK: has anyone ever > tried to debug why a filter is re-executing? One often ends up in the > weeds of vtkExecutive and subclass and is fraught with frustration. > Now, imagine that the vtkExecutive subclass just generated a log > indicate which pipeline pass it's executing, and why -- things would > be so easy! The log could be added only at higher levels of verbosity, > thus not pollute application logs with internal details, but would be > easily generate-able/accessible when needed. Same is true for > rendering pipelines, determining if the VBOs, for example, are being > regenerated and why can be easily logged and aid tracking down > performance issues. > > If we are convinced of the need for a logging support, then the > question becomes which logging library to use? I have been using for > loguru[1] with great success for a multi-threaded app. I love it's > output generation style, plus how well it handles logs from multiple > threads. It's C++ friendly, header only, minimal external > dependencies. > > Thoughts? Suggestions? > > Utkarsh > > > [1] https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fgithub.com%2Femilk%2Floguru&data=02% > 7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32% > 7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata= > CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&reserved=0 > _______________________________________________ > Powered by https://na01.safelinks.protection.outlook.com/?url= > www.kitware.com&data=02%7C01%7Classo%40queensu.ca% > 7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b > 925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un% > 2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > Visit other Kitware open-source projects at https://na01.safelinks. > protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com% > 2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca% > 7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b > 925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M% > 2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > Search the list archives at: https://na01.safelinks. > protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org% > 2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca% > 7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b > 925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNT > liI0U5Ax3yZ%2Bs%3D&reserved=0 > > Follow this link to subscribe/unsubscribe: > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo% > 2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca% > 7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b > 925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CM > olWwPCpzSgj3A%3D&reserved=0 > > _______________________________________________ > Powered by https://na01.safelinks.protection.outlook.com/?url= > www.kitware.com&data=02%7C01%7Classo%40queensu.ca% > 7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b > 925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un% > 2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > Visit other Kitware open-source projects at https://na01.safelinks. > protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com% > 2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca% > 7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b > 925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M% > 2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > Search the list archives at: https://na01.safelinks. > protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org% > 2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca% > 7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b > 925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNT > liI0U5Ax3yZ%2Bs%3D&reserved=0 > > Follow this link to subscribe/unsubscribe: > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo% > 2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca% > 7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b > 925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CM > olWwPCpzSgj3A%3D&reserved=0 > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue Aug 7 17:55:32 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 7 Aug 2018 17:55:32 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: +1, lending moral support for the idea of better log facilities. +0 for loguru. +1 for yeah by all means lets use something standard and good but -1 for any new non critical dependency Although I too have only rarely ever found vtkDebugMacro to be useful in practice I still think it should feed into the new logs rather than be some independent feature. Same goes for timerlogs - they should interoperate sooner rather than later. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti wrote: > > +1. The loguru outputs I've seen are very nice. > > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I > > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic. > > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso wrote: >> >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated? >> >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity. >> >> Andras >> ________________________________ >> From: "Scott, W Alan via vtk-developers" >> Sent: Tuesday, August 7, 2018 6:38 PM >> To: Ayachit, Utkarsh (External Contacts); vtk-developers at vtk.org >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging >> >> Great idea. For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable. >> >> Alan >> >> ________________________________________ >> From: vtk-developers on behalf of Utkarsh Ayachit >> Sent: Tuesday, August 7, 2018 8:29 AM >> To: vtk-developers at vtk.org >> Subject: [EXTERNAL] [vtk-developers] Support for logging >> >> Folks, >> >> Of late I've been finding myself needing some sort of logging support >> when debugging complex issues in ParaView and the more I thought about >> it, the more I realized it should really be in VTK too and hence this >> email. >> >> I wonder what folks thought about adding support for generating logs >> to VTK. This goes beyond the vtkTimerLog we currently have. >> vtkTimerLog is great to log filter execution times etc. but it lacks >> features like levels of verbosity, among others that are needed in a >> general purpose logging infrastructure. We could potentially make >> vtkTImerLog use the chosen logging infrastructure under the covers, >> but that's a separate discussion and not entirely relevant to the >> topic at hand. >> >> To illustrate a case where this is useful in VTK: has anyone ever >> tried to debug why a filter is re-executing? One often ends up in the >> weeds of vtkExecutive and subclass and is fraught with frustration. >> Now, imagine that the vtkExecutive subclass just generated a log >> indicate which pipeline pass it's executing, and why -- things would >> be so easy! The log could be added only at higher levels of verbosity, >> thus not pollute application logs with internal details, but would be >> easily generate-able/accessible when needed. Same is true for >> rendering pipelines, determining if the VBOs, for example, are being >> regenerated and why can be easily logged and aid tracking down >> performance issues. >> >> If we are convinced of the need for a logging support, then the >> question becomes which logging library to use? I have been using for >> loguru[1] with great success for a multi-threaded app. I love it's >> output generation style, plus how well it handles logs from multiple >> threads. It's C++ friendly, header only, minimal external >> dependencies. >> >> Thoughts? Suggestions? >> >> Utkarsh >> >> >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&reserved=0 >> _______________________________________________ >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 >> >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 >> >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 >> >> Follow this link to subscribe/unsubscribe: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 >> >> _______________________________________________ >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 >> >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 >> >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 >> >> Follow this link to subscribe/unsubscribe: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From utkarsh.ayachit at kitware.com Wed Aug 8 08:27:21 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 8 Aug 2018 08:27:21 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: @Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate. I'd recommend scanning the logs generated by loguru. They are immensely superior is quality than any VTK-based log dump. While we could change all of the message processing to go via the logging infrastructure, that'd probably be a separate discussion since it'll depend greatly on which logging infrastructure we pick. @Dave , I understand your reluctance for new dependencies, but "use something standard" and no external dependency are inherently contradictory :). `loguru` is header only. We could "wrap" it under a VTK-specific header and then use loguru internally, only if enabled. But since logs should always be generatable to be useful, I don't see who would want to build without logging enabled. On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle wrote: > > +1, lending moral support for the idea of better log facilities. > > +0 for loguru. +1 for yeah by all means lets use something standard > and good but -1 for any new non critical dependency > > Although I too have only rarely ever found vtkDebugMacro to be useful > in practice I still think it should feed into the new logs rather than > be some independent feature. Same goes for timerlogs - they should > interoperate sooner rather than later. > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti > wrote: > > > > +1. The loguru outputs I've seen are very nice. > > > > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I > > > > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic. > > > > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso wrote: > >> > >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated? > >> > >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity. > >> > >> Andras > >> ________________________________ > >> From: "Scott, W Alan via vtk-developers" > >> Sent: Tuesday, August 7, 2018 6:38 PM > >> To: Ayachit, Utkarsh (External Contacts); vtk-developers at vtk.org > >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging > >> > >> Great idea. For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable. > >> > >> Alan > >> > >> ________________________________________ > >> From: vtk-developers on behalf of Utkarsh Ayachit > >> Sent: Tuesday, August 7, 2018 8:29 AM > >> To: vtk-developers at vtk.org > >> Subject: [EXTERNAL] [vtk-developers] Support for logging > >> > >> Folks, > >> > >> Of late I've been finding myself needing some sort of logging support > >> when debugging complex issues in ParaView and the more I thought about > >> it, the more I realized it should really be in VTK too and hence this > >> email. > >> > >> I wonder what folks thought about adding support for generating logs > >> to VTK. This goes beyond the vtkTimerLog we currently have. > >> vtkTimerLog is great to log filter execution times etc. but it lacks > >> features like levels of verbosity, among others that are needed in a > >> general purpose logging infrastructure. We could potentially make > >> vtkTImerLog use the chosen logging infrastructure under the covers, > >> but that's a separate discussion and not entirely relevant to the > >> topic at hand. > >> > >> To illustrate a case where this is useful in VTK: has anyone ever > >> tried to debug why a filter is re-executing? One often ends up in the > >> weeds of vtkExecutive and subclass and is fraught with frustration. > >> Now, imagine that the vtkExecutive subclass just generated a log > >> indicate which pipeline pass it's executing, and why -- things would > >> be so easy! The log could be added only at higher levels of verbosity, > >> thus not pollute application logs with internal details, but would be > >> easily generate-able/accessible when needed. Same is true for > >> rendering pipelines, determining if the VBOs, for example, are being > >> regenerated and why can be easily logged and aid tracking down > >> performance issues. > >> > >> If we are convinced of the need for a logging support, then the > >> question becomes which logging library to use? I have been using for > >> loguru[1] with great success for a multi-threaded app. I love it's > >> output generation style, plus how well it handles logs from multiple > >> threads. It's C++ friendly, header only, minimal external > >> dependencies. > >> > >> Thoughts? Suggestions? > >> > >> Utkarsh > >> > >> > >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&reserved=0 > >> _______________________________________________ > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > >> > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > >> > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > >> > >> Follow this link to subscribe/unsubscribe: > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > >> > >> _______________________________________________ > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > >> > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > >> > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > >> > >> Follow this link to subscribe/unsubscribe: > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > >> > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> https://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From robert.maynard at kitware.com Wed Aug 8 08:30:38 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 8 Aug 2018 08:30:38 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: What are the plans for controlling logging when running MPI jobs? Will each rank have a separate log file? I would think for larger MPI runs we might want logging disabled by default On Wed, Aug 8, 2018 at 8:28 AM Utkarsh Ayachit wrote: > > @Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate. > I'd recommend scanning the logs generated by loguru. They are > immensely superior is quality than any VTK-based log dump. While we > could change all of the message processing to go via the logging > infrastructure, that'd probably be a separate discussion since it'll > depend greatly on which logging infrastructure we pick. > > @Dave , I understand your reluctance for new dependencies, but "use > something standard" and no external dependency are inherently > contradictory :). `loguru` is header only. We could "wrap" it under a > VTK-specific header and then use loguru internally, only if enabled. > But since logs should always be generatable to be useful, I don't see > who would want to build without logging enabled. > > > On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle wrote: > > > > +1, lending moral support for the idea of better log facilities. > > > > +0 for loguru. +1 for yeah by all means lets use something standard > > and good but -1 for any new non critical dependency > > > > Although I too have only rarely ever found vtkDebugMacro to be useful > > in practice I still think it should feed into the new logs rather than > > be some independent feature. Same goes for timerlogs - they should > > interoperate sooner rather than later. > > > > David E DeMarle > > Kitware, Inc. > > Principal Engineer > > 21 Corporate Drive > > Clifton Park, NY 12065-8662 > > Phone: 518-881-4909 > > > > On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti > > wrote: > > > > > > +1. The loguru outputs I've seen are very nice. > > > > > > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I > > > > > > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic. > > > > > > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso wrote: > > >> > > >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated? > > >> > > >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity. > > >> > > >> Andras > > >> ________________________________ > > >> From: "Scott, W Alan via vtk-developers" > > >> Sent: Tuesday, August 7, 2018 6:38 PM > > >> To: Ayachit, Utkarsh (External Contacts); vtk-developers at vtk.org > > >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging > > >> > > >> Great idea. For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable. > > >> > > >> Alan > > >> > > >> ________________________________________ > > >> From: vtk-developers on behalf of Utkarsh Ayachit > > >> Sent: Tuesday, August 7, 2018 8:29 AM > > >> To: vtk-developers at vtk.org > > >> Subject: [EXTERNAL] [vtk-developers] Support for logging > > >> > > >> Folks, > > >> > > >> Of late I've been finding myself needing some sort of logging support > > >> when debugging complex issues in ParaView and the more I thought about > > >> it, the more I realized it should really be in VTK too and hence this > > >> email. > > >> > > >> I wonder what folks thought about adding support for generating logs > > >> to VTK. This goes beyond the vtkTimerLog we currently have. > > >> vtkTimerLog is great to log filter execution times etc. but it lacks > > >> features like levels of verbosity, among others that are needed in a > > >> general purpose logging infrastructure. We could potentially make > > >> vtkTImerLog use the chosen logging infrastructure under the covers, > > >> but that's a separate discussion and not entirely relevant to the > > >> topic at hand. > > >> > > >> To illustrate a case where this is useful in VTK: has anyone ever > > >> tried to debug why a filter is re-executing? One often ends up in the > > >> weeds of vtkExecutive and subclass and is fraught with frustration. > > >> Now, imagine that the vtkExecutive subclass just generated a log > > >> indicate which pipeline pass it's executing, and why -- things would > > >> be so easy! The log could be added only at higher levels of verbosity, > > >> thus not pollute application logs with internal details, but would be > > >> easily generate-able/accessible when needed. Same is true for > > >> rendering pipelines, determining if the VBOs, for example, are being > > >> regenerated and why can be easily logged and aid tracking down > > >> performance issues. > > >> > > >> If we are convinced of the need for a logging support, then the > > >> question becomes which logging library to use? I have been using for > > >> loguru[1] with great success for a multi-threaded app. I love it's > > >> output generation style, plus how well it handles logs from multiple > > >> threads. It's C++ friendly, header only, minimal external > > >> dependencies. > > >> > > >> Thoughts? Suggestions? > > >> > > >> Utkarsh > > >> > > >> > > >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&reserved=0 > > >> _______________________________________________ > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > >> > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > >> > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > > >> > > >> Follow this link to subscribe/unsubscribe: > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > > >> > > >> _______________________________________________ > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > >> > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > >> > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > > >> > > >> Follow this link to subscribe/unsubscribe: > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > > >> > > >> > > >> _______________________________________________ > > >> Powered by www.kitware.com > > >> > > >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > >> > > >> Search the list archives at: http://markmail.org/search/?q=vtk-developers > > >> > > >> Follow this link to subscribe/unsubscribe: > > >> https://public.kitware.com/mailman/listinfo/vtk-developers > > >> > > >> > > > > > > _______________________________________________ > > > Powered by www.kitware.com > > > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > > > Follow this link to subscribe/unsubscribe: > > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From utkarsh.ayachit at kitware.com Wed Aug 8 08:45:52 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 8 Aug 2018 08:45:52 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: Logging will be disabled by default. If we add decide to add `vtkErrorMacro`, `vtkWarningMacro` to log, then those will get logged by default. One will request additional verbosity either via environment variables or command line arguments or something. For MPI, I think it should indeed be separate files per rank, if logging to file was requested. On Wed, Aug 8, 2018 at 8:31 AM Robert Maynard wrote: > > What are the plans for controlling logging when running MPI jobs? Will > each rank have a separate log file? I would think for larger MPI runs > we might want logging disabled by default > On Wed, Aug 8, 2018 at 8:28 AM Utkarsh Ayachit > wrote: > > > > @Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate. > > I'd recommend scanning the logs generated by loguru. They are > > immensely superior is quality than any VTK-based log dump. While we > > could change all of the message processing to go via the logging > > infrastructure, that'd probably be a separate discussion since it'll > > depend greatly on which logging infrastructure we pick. > > > > @Dave , I understand your reluctance for new dependencies, but "use > > something standard" and no external dependency are inherently > > contradictory :). `loguru` is header only. We could "wrap" it under a > > VTK-specific header and then use loguru internally, only if enabled. > > But since logs should always be generatable to be useful, I don't see > > who would want to build without logging enabled. > > > > > > On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle wrote: > > > > > > +1, lending moral support for the idea of better log facilities. > > > > > > +0 for loguru. +1 for yeah by all means lets use something standard > > > and good but -1 for any new non critical dependency > > > > > > Although I too have only rarely ever found vtkDebugMacro to be useful > > > in practice I still think it should feed into the new logs rather than > > > be some independent feature. Same goes for timerlogs - they should > > > interoperate sooner rather than later. > > > > > > David E DeMarle > > > Kitware, Inc. > > > Principal Engineer > > > 21 Corporate Drive > > > Clifton Park, NY 12065-8662 > > > Phone: 518-881-4909 > > > > > > On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti > > > wrote: > > > > > > > > +1. The loguru outputs I've seen are very nice. > > > > > > > > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I > > > > > > > > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic. > > > > > > > > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso wrote: > > > >> > > > >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated? > > > >> > > > >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity. > > > >> > > > >> Andras > > > >> ________________________________ > > > >> From: "Scott, W Alan via vtk-developers" > > > >> Sent: Tuesday, August 7, 2018 6:38 PM > > > >> To: Ayachit, Utkarsh (External Contacts); vtk-developers at vtk.org > > > >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging > > > >> > > > >> Great idea. For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable. > > > >> > > > >> Alan > > > >> > > > >> ________________________________________ > > > >> From: vtk-developers on behalf of Utkarsh Ayachit > > > >> Sent: Tuesday, August 7, 2018 8:29 AM > > > >> To: vtk-developers at vtk.org > > > >> Subject: [EXTERNAL] [vtk-developers] Support for logging > > > >> > > > >> Folks, > > > >> > > > >> Of late I've been finding myself needing some sort of logging support > > > >> when debugging complex issues in ParaView and the more I thought about > > > >> it, the more I realized it should really be in VTK too and hence this > > > >> email. > > > >> > > > >> I wonder what folks thought about adding support for generating logs > > > >> to VTK. This goes beyond the vtkTimerLog we currently have. > > > >> vtkTimerLog is great to log filter execution times etc. but it lacks > > > >> features like levels of verbosity, among others that are needed in a > > > >> general purpose logging infrastructure. We could potentially make > > > >> vtkTImerLog use the chosen logging infrastructure under the covers, > > > >> but that's a separate discussion and not entirely relevant to the > > > >> topic at hand. > > > >> > > > >> To illustrate a case where this is useful in VTK: has anyone ever > > > >> tried to debug why a filter is re-executing? One often ends up in the > > > >> weeds of vtkExecutive and subclass and is fraught with frustration. > > > >> Now, imagine that the vtkExecutive subclass just generated a log > > > >> indicate which pipeline pass it's executing, and why -- things would > > > >> be so easy! The log could be added only at higher levels of verbosity, > > > >> thus not pollute application logs with internal details, but would be > > > >> easily generate-able/accessible when needed. Same is true for > > > >> rendering pipelines, determining if the VBOs, for example, are being > > > >> regenerated and why can be easily logged and aid tracking down > > > >> performance issues. > > > >> > > > >> If we are convinced of the need for a logging support, then the > > > >> question becomes which logging library to use? I have been using for > > > >> loguru[1] with great success for a multi-threaded app. I love it's > > > >> output generation style, plus how well it handles logs from multiple > > > >> threads. It's C++ friendly, header only, minimal external > > > >> dependencies. > > > >> > > > >> Thoughts? Suggestions? > > > >> > > > >> Utkarsh > > > >> > > > >> > > > >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&reserved=0 > > > >> _______________________________________________ > > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > > >> > > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > > >> > > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > > > >> > > > >> Follow this link to subscribe/unsubscribe: > > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > > > >> > > > >> _______________________________________________ > > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > > >> > > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > > >> > > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > > > >> > > > >> Follow this link to subscribe/unsubscribe: > > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > > > >> > > > >> > > > >> _______________________________________________ > > > >> Powered by www.kitware.com > > > >> > > > >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > >> > > > >> Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > >> > > > >> Follow this link to subscribe/unsubscribe: > > > >> https://public.kitware.com/mailman/listinfo/vtk-developers > > > >> > > > >> > > > > > > > > _______________________________________________ > > > > Powered by www.kitware.com > > > > > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > > > > > Follow this link to subscribe/unsubscribe: > > > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > _______________________________________________ > > > Powered by www.kitware.com > > > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > > > Follow this link to subscribe/unsubscribe: > > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > https://public.kitware.com/mailman/listinfo/vtk-developers > > From dave.demarle at kitware.com Wed Aug 8 10:42:00 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 8 Aug 2018 10:42:00 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: > > @Dave , I understand your reluctance for new dependencies, but "use > something standard" and no external dependency are inherently > contradictory :). `loguru` is header only. We could "wrap" it under a > VTK-specific header and then use loguru internally, only if enabled. > But since logs should always be generatable to be useful, I don't see > who would want to build without logging enabled. > :) Yes, loguru seems really lightweight. As long as we use Ben's best practices so that it can be updated and upstreamed and use system we'll be fine. Until the logging proves itself to be "essential enough" (whatever that means) I recommend that we keep the dependency optional. Then when someone is trying to deploy a VTK enabled app on some strange system or distro and they hit a hard and weirdo compile error, they can make due. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Aug 8, 2018 at 8:27 AM Utkarsh Ayachit wrote: > @Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate. > I'd recommend scanning the logs generated by loguru. They are > immensely superior is quality than any VTK-based log dump. While we > could change all of the message processing to go via the logging > infrastructure, that'd probably be a separate discussion since it'll > depend greatly on which logging infrastructure we pick. > > @Dave , I understand your reluctance for new dependencies, but "use > something standard" and no external dependency are inherently > contradictory :). `loguru` is header only. We could "wrap" it under a > VTK-specific header and then use loguru internally, only if enabled. > But since logs should always be generatable to be useful, I don't see > who would want to build without logging enabled. > > > On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle > wrote: > > > > +1, lending moral support for the idea of better log facilities. > > > > +0 for loguru. +1 for yeah by all means lets use something standard > > and good but -1 for any new non critical dependency > > > > Although I too have only rarely ever found vtkDebugMacro to be useful > > in practice I still think it should feed into the new logs rather than > > be some independent feature. Same goes for timerlogs - they should > > interoperate sooner rather than later. > > > > David E DeMarle > > Kitware, Inc. > > Principal Engineer > > 21 Corporate Drive > > Clifton Park, NY 12065-8662 > > Phone: 518-881-4909 > > > > On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti > > wrote: > > > > > > +1. The loguru outputs I've seen are very nice. > > > > > > I tend to find the vtkObject::Debug logging to be largely useless, as > it prints very verbose information and it's usually easier to just add a > manual print statement when something like this is needed. Source > modification is usually needed to set the Debug flag on, and at that point, > why not just dump the exact piece of info we care about, when we care about > it? I > > > > > > Something that would let us categorize the log entries ('rendering' > for mappers/renderers, 'pipeline' for executive info, 'filter' for > algorithm details, 'dataset' for dataset changes, 'verbose' for > every-little-set-and-get-ever) to more easily filter out the stuff we're > not interested in would be fantastic. > > > > > > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso wrote: > > >> > > >> VTK has already a logging API that sends messages to stdout/stderr by > default but it can be easily configured to send messages to any logging > system. Do you mean you would keep the current logging API and just change > the default logging backend to something more sophisticated? > > >> > > >> Somewhat related issue: For me, it has never been completely clear > how VTK debug logs could be used in practice, as most often it is very > difficult to set DebugOn for an object (or group of relevant objects). It > would be probably better to enable logging by default for all objects and > split current debug level to 3 levels (info/debug/trace) for better control > of verbosity. > > >> > > >> Andras > > >> ________________________________ > > >> From: "Scott, W Alan via vtk-developers" < > vtk-developers at public.kitware.com> > > >> Sent: Tuesday, August 7, 2018 6:38 PM > > >> To: Ayachit, Utkarsh (External Contacts); vtk-developers at vtk.org > > >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging > > >> > > >> Great idea. For someone that doesn't know where to place > breakpoints, but has to try to debug datasets that cannot be sent to > Kitware, this would be incredibly valuable. > > >> > > >> Alan > > >> > > >> ________________________________________ > > >> From: vtk-developers on > behalf of Utkarsh Ayachit > > >> Sent: Tuesday, August 7, 2018 8:29 AM > > >> To: vtk-developers at vtk.org > > >> Subject: [EXTERNAL] [vtk-developers] Support for logging > > >> > > >> Folks, > > >> > > >> Of late I've been finding myself needing some sort of logging support > > >> when debugging complex issues in ParaView and the more I thought about > > >> it, the more I realized it should really be in VTK too and hence this > > >> email. > > >> > > >> I wonder what folks thought about adding support for generating logs > > >> to VTK. This goes beyond the vtkTimerLog we currently have. > > >> vtkTimerLog is great to log filter execution times etc. but it lacks > > >> features like levels of verbosity, among others that are needed in a > > >> general purpose logging infrastructure. We could potentially make > > >> vtkTImerLog use the chosen logging infrastructure under the covers, > > >> but that's a separate discussion and not entirely relevant to the > > >> topic at hand. > > >> > > >> To illustrate a case where this is useful in VTK: has anyone ever > > >> tried to debug why a filter is re-executing? One often ends up in the > > >> weeds of vtkExecutive and subclass and is fraught with frustration. > > >> Now, imagine that the vtkExecutive subclass just generated a log > > >> indicate which pipeline pass it's executing, and why -- things would > > >> be so easy! The log could be added only at higher levels of verbosity, > > >> thus not pollute application logs with internal details, but would be > > >> easily generate-able/accessible when needed. Same is true for > > >> rendering pipelines, determining if the VBOs, for example, are being > > >> regenerated and why can be easily logged and aid tracking down > > >> performance issues. > > >> > > >> If we are convinced of the need for a logging support, then the > > >> question becomes which logging library to use? I have been using for > > >> loguru[1] with great success for a multi-threaded app. I love it's > > >> output generation style, plus how well it handles logs from multiple > > >> threads. It's C++ friendly, header only, minimal external > > >> dependencies. > > >> > > >> Thoughts? Suggestions? > > >> > > >> Utkarsh > > >> > > >> > > >> [1] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&reserved=0 > > >> _______________________________________________ > > >> Powered by > https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > >> > > >> Visit other Kitware open-source projects at > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > >> > > >> Search the list archives at: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > > >> > > >> Follow this link to subscribe/unsubscribe: > > >> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > > >> > > >> _______________________________________________ > > >> Powered by > https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > >> > > >> Visit other Kitware open-source projects at > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > >> > > >> Search the list archives at: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > > >> > > >> Follow this link to subscribe/unsubscribe: > > >> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > > >> > > >> > > >> _______________________________________________ > > >> Powered by www.kitware.com > > >> > > >> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > >> > > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > >> > > >> Follow this link to subscribe/unsubscribe: > > >> https://public.kitware.com/mailman/listinfo/vtk-developers > > >> > > >> > > > > > > _______________________________________________ > > > Powered by www.kitware.com > > > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > > > Follow this link to subscribe/unsubscribe: > > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Aug 8 10:47:01 2018 From: DLRdave at aol.com (David Cole) Date: Wed, 8 Aug 2018 10:47:01 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: As strictly a client of VTK, I would like to express the strong desire to NOT get yet-another-logger added to my app just because I link in VTK. Please make sure it's "opt-in" only. We have two apps, one already uses log4cpp, and one uses g2log, and we just went through a large pain trying to turn off logging in one of our other client libraries. So.... if you do add this, please make it off by default, and easy to switch on and off entirely. (And easy to integrate with any pre-existing backend application logging facility...) Thanks, David C. On Wed, Aug 8, 2018 at 8:45 AM Utkarsh Ayachit wrote: > > Logging will be disabled by default. If we add decide to add > `vtkErrorMacro`, `vtkWarningMacro` to log, then those will get logged > by default. One will request additional verbosity either via > environment variables or command line arguments or something. > > For MPI, I think it should indeed be separate files per rank, if > logging to file was requested. > On Wed, Aug 8, 2018 at 8:31 AM Robert Maynard > wrote: > > > > What are the plans for controlling logging when running MPI jobs? Will > > each rank have a separate log file? I would think for larger MPI runs > > we might want logging disabled by default > > On Wed, Aug 8, 2018 at 8:28 AM Utkarsh Ayachit > > wrote: > > > > > > @Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate. > > > I'd recommend scanning the logs generated by loguru. They are > > > immensely superior is quality than any VTK-based log dump. While we > > > could change all of the message processing to go via the logging > > > infrastructure, that'd probably be a separate discussion since it'll > > > depend greatly on which logging infrastructure we pick. > > > > > > @Dave , I understand your reluctance for new dependencies, but "use > > > something standard" and no external dependency are inherently > > > contradictory :). `loguru` is header only. We could "wrap" it under a > > > VTK-specific header and then use loguru internally, only if enabled. > > > But since logs should always be generatable to be useful, I don't see > > > who would want to build without logging enabled. > > > > > > > > > On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle wrote: > > > > > > > > +1, lending moral support for the idea of better log facilities. > > > > > > > > +0 for loguru. +1 for yeah by all means lets use something standard > > > > and good but -1 for any new non critical dependency > > > > > > > > Although I too have only rarely ever found vtkDebugMacro to be useful > > > > in practice I still think it should feed into the new logs rather than > > > > be some independent feature. Same goes for timerlogs - they should > > > > interoperate sooner rather than later. > > > > > > > > David E DeMarle > > > > Kitware, Inc. > > > > Principal Engineer > > > > 21 Corporate Drive > > > > Clifton Park, NY 12065-8662 > > > > Phone: 518-881-4909 > > > > > > > > On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti > > > > wrote: > > > > > > > > > > +1. The loguru outputs I've seen are very nice. > > > > > > > > > > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I > > > > > > > > > > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic. > > > > > > > > > > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso wrote: > > > > >> > > > > >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated? > > > > >> > > > > >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity. > > > > >> > > > > >> Andras > > > > >> ________________________________ > > > > >> From: "Scott, W Alan via vtk-developers" > > > > >> Sent: Tuesday, August 7, 2018 6:38 PM > > > > >> To: Ayachit, Utkarsh (External Contacts); vtk-developers at vtk.org > > > > >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging > > > > >> > > > > >> Great idea. For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable. > > > > >> > > > > >> Alan > > > > >> > > > > >> ________________________________________ > > > > >> From: vtk-developers on behalf of Utkarsh Ayachit > > > > >> Sent: Tuesday, August 7, 2018 8:29 AM > > > > >> To: vtk-developers at vtk.org > > > > >> Subject: [EXTERNAL] [vtk-developers] Support for logging > > > > >> > > > > >> Folks, > > > > >> > > > > >> Of late I've been finding myself needing some sort of logging support > > > > >> when debugging complex issues in ParaView and the more I thought about > > > > >> it, the more I realized it should really be in VTK too and hence this > > > > >> email. > > > > >> > > > > >> I wonder what folks thought about adding support for generating logs > > > > >> to VTK. This goes beyond the vtkTimerLog we currently have. > > > > >> vtkTimerLog is great to log filter execution times etc. but it lacks > > > > >> features like levels of verbosity, among others that are needed in a > > > > >> general purpose logging infrastructure. We could potentially make > > > > >> vtkTImerLog use the chosen logging infrastructure under the covers, > > > > >> but that's a separate discussion and not entirely relevant to the > > > > >> topic at hand. > > > > >> > > > > >> To illustrate a case where this is useful in VTK: has anyone ever > > > > >> tried to debug why a filter is re-executing? One often ends up in the > > > > >> weeds of vtkExecutive and subclass and is fraught with frustration. > > > > >> Now, imagine that the vtkExecutive subclass just generated a log > > > > >> indicate which pipeline pass it's executing, and why -- things would > > > > >> be so easy! The log could be added only at higher levels of verbosity, > > > > >> thus not pollute application logs with internal details, but would be > > > > >> easily generate-able/accessible when needed. Same is true for > > > > >> rendering pipelines, determining if the VBOs, for example, are being > > > > >> regenerated and why can be easily logged and aid tracking down > > > > >> performance issues. > > > > >> > > > > >> If we are convinced of the need for a logging support, then the > > > > >> question becomes which logging library to use? I have been using for > > > > >> loguru[1] with great success for a multi-threaded app. I love it's > > > > >> output generation style, plus how well it handles logs from multiple > > > > >> threads. It's C++ friendly, header only, minimal external > > > > >> dependencies. > > > > >> > > > > >> Thoughts? Suggestions? > > > > >> > > > > >> Utkarsh > > > > >> > > > > >> > > > > >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&reserved=0 > > > > >> _______________________________________________ > > > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > > > >> > > > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > > > >> > > > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > > > > >> > > > > >> Follow this link to subscribe/unsubscribe: > > > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > > > > >> > > > > >> _______________________________________________ > > > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&reserved=0 > > > > >> > > > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&reserved=0 > > > > >> > > > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&reserved=0 > > > > >> > > > > >> Follow this link to subscribe/unsubscribe: > > > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&reserved=0 > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> Powered by www.kitware.com > > > > >> > > > > >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > >> > > > > >> Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > >> > > > > >> Follow this link to subscribe/unsubscribe: > > > > >> https://public.kitware.com/mailman/listinfo/vtk-developers > > > > >> > > > > >> > > > > > > > > > > _______________________________________________ > > > > > Powered by www.kitware.com > > > > > > > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > > > > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > > > > > > > Follow this link to subscribe/unsubscribe: > > > > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > > _______________________________________________ > > > > Powered by www.kitware.com > > > > > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > > > > > Follow this link to subscribe/unsubscribe: > > > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > _______________________________________________ > > > Powered by www.kitware.com > > > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > > > Follow this link to subscribe/unsubscribe: > > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From utkarsh.ayachit at kitware.com Wed Aug 8 10:53:39 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 8 Aug 2018 10:53:39 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: > So.... if you do add this, please make it off by default, and easy to > switch on and off entirely. (And easy to integrate with any > pre-existing backend application logging facility...) Indeed. Logging will be off by default. From bill.lorensen at gmail.com Wed Aug 8 11:46:08 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 8 Aug 2018 08:46:08 -0700 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: ITK has a logging API. It may be a starting point for to "wrap" a third party resource. See: https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkLoggerManager.h On Wed, Aug 8, 2018 at 7:53 AM, Utkarsh Ayachit wrote: >> So.... if you do add this, please make it off by default, and easy to >> switch on and off entirely. (And easy to integrate with any >> pre-existing backend application logging facility...) > > Indeed. Logging will be off by default. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsParadise at noware dot com From sean at rogue-research.com Wed Aug 8 14:53:30 2018 From: sean at rogue-research.com (Sean McBride) Date: Wed, 8 Aug 2018 14:53:30 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> Message-ID: <20180808185330.295088589@mail.rogue-research.com> On Wed, 8 Aug 2018 10:47:01 -0400, David Cole via vtk-developers said: >As strictly a client of VTK, I would like to express the strong desire >to NOT get yet-another-logger added to my app just because I link in >VTK. Please make sure it's "opt-in" only. We have two apps, one >already uses log4cpp, and one uses g2log, and we just went through a >large pain trying to turn off logging in one of our other client >libraries. I had a similar thought. I haven't looked at this loguru, but hopefully you can choose where it logs things to. On macOS for example, it would be nice if VTK logging eventually invokes the os_log functions in usr/include/os/log.h. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From bill.lorensen at gmail.com Wed Aug 8 16:08:35 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 8 Aug 2018 13:08:35 -0700 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: <20180808185330.295088589@mail.rogue-research.com> References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> <20180808185330.295088589@mail.rogue-research.com> Message-ID: We definitely should hide what ever third party spi. On Wed, Aug 8, 2018, 11:53 AM Sean McBride wrote: > On Wed, 8 Aug 2018 10:47:01 -0400, David Cole via vtk-developers said: > > >As strictly a client of VTK, I would like to express the strong desire > >to NOT get yet-another-logger added to my app just because I link in > >VTK. Please make sure it's "opt-in" only. We have two apps, one > >already uses log4cpp, and one uses g2log, and we just went through a > >large pain trying to turn off logging in one of our other client > >libraries. > > I had a similar thought. I haven't looked at this loguru, but hopefully > you can choose where it logs things to. On macOS for example, it would be > nice if VTK logging eventually invokes the os_log functions in > usr/include/os/log.h. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcfr at kitware.com Thu Aug 9 00:36:49 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 9 Aug 2018 00:36:49 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> <20180808185330.295088589@mail.rogue-research.com> Message-ID: Hi, Here are some suggestions and comment: * using "loguru" (or any other logging backend) should be an implementation details specific to the application using the library (e.g of application ParaView, 3D Slicer, VTK examples, VTK tests, and many more). * existing logging macros (vtkErrorMacro, vtkDebugMacro, ...) should be kept around along with their existing behavior as well as the vtkOutputWindow * new categorical logging macro should be introduced. - each message would be associated with a type (info, error, warning), a category (e.g vtk.rendering.opengl2.shaderprogram) and a context (line, file, function) - for sake of performance, context would be available only for Debug (and may be RelWithDebInfo) or only if explicitly enabled - enable/disable logging at run-time based on rules, ... - this presentation nicely summarizes the type of features that could be integrated in VTK. See https://www.kdab.com/wp-content/uploads/stories/ slides/Day2/KaiKoehne_Qt%20Logging%20Framework%2016_9_0.pdf * since it is not uncommon to have application using both ITK and VTK, would also be nice to discussed with ITK community Such approach would allow to gradually transition existing VTK module to the new categorical logging and would prevent existing user code from breaking On Wed, Aug 8, 2018 at 4:08 PM, Bill Lorensen wrote: > We definitely should hide what ever third party spi. > > On Wed, Aug 8, 2018, 11:53 AM Sean McBride > wrote: > >> On Wed, 8 Aug 2018 10:47:01 -0400, David Cole via vtk-developers said: >> >> >As strictly a client of VTK, I would like to express the strong desire >> >to NOT get yet-another-logger added to my app just because I link in >> >VTK. Please make sure it's "opt-in" only. We have two apps, one >> >already uses log4cpp, and one uses g2log, and we just went through a >> >large pain trying to turn off logging in one of our other client >> >libraries. >> >> I had a similar thought. I haven't looked at this loguru, but hopefully >> you can choose where it logs things to. On macOS for example, it would be >> nice if VTK logging eventually invokes the os_log functions in >> usr/include/os/log.h. >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skemobob at gmail.com Thu Aug 9 02:50:02 2018 From: skemobob at gmail.com (viacheslav) Date: Wed, 8 Aug 2018 23:50:02 -0700 (MST) Subject: [vtk-developers] Paraview connection to hive via ODBC Message-ID: <1533797402534-0.post@n5.nabble.com> Does anyone tried to connect to Apache hive via odbc? Need some help with it -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From allison.vacanti at kitware.com Thu Aug 9 09:36:10 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Thu, 9 Aug 2018 09:36:10 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> <20180808185330.295088589@mail.rogue-research.com> Message-ID: While we're possibly retooling logging... I'd love to see the behavior of these macros change to reduce the verbosity. If we want vtkDebugMacro to log every set and get, ok, but it'd be nice to have the messages shortened. Right now, every debug/warning prints 3 lines, eg """ Warning: In /path/to/source/file, line XXX vtkClassName (0xOBJ_ADDRESS): Actual log message. """ I do find the extra information to be extremely valuable, but with the amount of data logged by debug macros, it becomes a chore to dig through the output. What if the log messages were compacted to something more dense, like: """ [Warning] Actual log message. (vtkClassName at 0xOBJ_ADDRESS, /path/to/source/file:XXX) """ Is this something that anyone else would find useful? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Aug 9 09:45:26 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 9 Aug 2018 06:45:26 -0700 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> <20180808185330.295088589@mail.rogue-research.com> Message-ID: The debug macro is only active for debug builds. On Thu, Aug 9, 2018, 6:36 AM Allie Vacanti wrote: > While we're possibly retooling logging... > > I'd love to see the behavior of these macros change to reduce the > verbosity. If we want vtkDebugMacro to log every set and get, ok, but it'd > be nice to have the messages shortened. Right now, every debug/warning > prints 3 lines, eg > > """ > Warning: In /path/to/source/file, line XXX > vtkClassName (0xOBJ_ADDRESS): Actual log message. > > """ > > I do find the extra information to be extremely valuable, but with the > amount of data logged by debug macros, it becomes a chore to dig through > the output. What if the log messages were compacted to something more > dense, like: > > """ > [Warning] Actual log message. (vtkClassName at 0xOBJ_ADDRESS, > /path/to/source/file:XXX) > """ > > Is this something that anyone else would find useful? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allison.vacanti at kitware.com Thu Aug 9 09:53:55 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Thu, 9 Aug 2018 09:53:55 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> <20180808185330.295088589@mail.rogue-research.com> Message-ID: On Thu, Aug 9, 2018 at 9:45 AM, Bill Lorensen wrote: > The debug macro is only active for debug builds. > Yes. I'm referring to the readability of the output when it's enabled. A few have mentioned that it's not terribly useful in its current state, and making the output more compact would be an improvement IMO. As it is, trying to watch the terminal while a program is executing is near impossible as it moves too quickly, and digging through the markup to find the relevant messages is tedious. Fitting 3x more messages in the same number of lines would improve both usecases for me. On Thu, Aug 9, 2018, 6:36 AM Allie Vacanti > wrote: > >> While we're possibly retooling logging... >> >> I'd love to see the behavior of these macros change to reduce the >> verbosity. If we want vtkDebugMacro to log every set and get, ok, but it'd >> be nice to have the messages shortened. Right now, every debug/warning >> prints 3 lines, eg >> >> """ >> Warning: In /path/to/source/file, line XXX >> vtkClassName (0xOBJ_ADDRESS): Actual log message. >> >> """ >> >> I do find the extra information to be extremely valuable, but with the >> amount of data logged by debug macros, it becomes a chore to dig through >> the output. What if the log messages were compacted to something more >> dense, like: >> >> """ >> [Warning] Actual log message. (vtkClassName at 0xOBJ_ADDRESS, >> /path/to/source/file:XXX) >> """ >> >> Is this something that anyone else would find useful? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Aug 9 10:19:29 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 9 Aug 2018 10:19:29 -0400 Subject: [vtk-developers] [EXTERNAL] Support for logging In-Reply-To: References: <1533659887385.2809@sandia.gov> <7bc8ed36-0cc0-41d2-b9e9-d0dc83607c2f@queensu.ca> <20180808185330.295088589@mail.rogue-research.com> Message-ID: I think some prototyping is in order before we down the rabbit hole. Allie, I'll sync up with you and see what would be good initial pass. Don't think I have enough time to do what everyone is suggesting soon, so I may have to table this for now. Thanks everyone for the feedback. Hopefully we can get back to this in near future. Utkarsh On Thu, Aug 9, 2018 at 9:54 AM Allie Vacanti wrote: > > On Thu, Aug 9, 2018 at 9:45 AM, Bill Lorensen wrote: >> >> The debug macro is only active for debug builds. > > > Yes. I'm referring to the readability of the output when it's enabled. A few have mentioned that it's not terribly useful in its current state, and making the output more compact would be an improvement IMO. > > As it is, trying to watch the terminal while a program is executing is near impossible as it moves too quickly, and digging through the markup to find the relevant messages is tedious. Fitting 3x more messages in the same number of lines would improve both usecases for me. > >> On Thu, Aug 9, 2018, 6:36 AM Allie Vacanti wrote: >>> >>> While we're possibly retooling logging... >>> >>> I'd love to see the behavior of these macros change to reduce the verbosity. If we want vtkDebugMacro to log every set and get, ok, but it'd be nice to have the messages shortened. Right now, every debug/warning prints 3 lines, eg >>> >>> """ >>> Warning: In /path/to/source/file, line XXX >>> vtkClassName (0xOBJ_ADDRESS): Actual log message. >>> >>> """ >>> >>> I do find the extra information to be extremely valuable, but with the amount of data logged by debug macros, it becomes a chore to dig through the output. What if the log messages were compacted to something more dense, like: >>> >>> """ >>> [Warning] Actual log message. (vtkClassName at 0xOBJ_ADDRESS, /path/to/source/file:XXX) >>> """ >>> >>> Is this something that anyone else would find useful? >>> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From rroemer at gmail.com Fri Aug 10 06:28:10 2018 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=c3=b6mer?=) Date: Fri, 10 Aug 2018 12:28:10 +0200 Subject: [vtk-developers] Static class member initialization in vtk_wrap_python3 Message-ID: <13db5361-9b19-3d1d-d031-aa8cd0a07d59@gmail.com> I have a static class member and I want to initialize it in vtk_wrap_python3. How can I do this? Best regards Ronald From pbergeron at spiria.com Mon Aug 13 20:24:54 2018 From: pbergeron at spiria.com (Patrick Bergeron) Date: Tue, 14 Aug 2018 00:24:54 +0000 Subject: [vtk-developers] Nvidia rtx? Message-ID: <7FF56FEF-1007-4109-ABC9-704DD80EB160@spiria.com> I am sitting in at siggraph where they are talking about the rtx cards and I saw the Paraview logo as an adopting technology. Paraview ans kitware (and vtk?) moving to rtx ray tracing? Woot? Sent from my iPhone From jonathan.borduas at caboma.com Mon Aug 13 20:40:41 2018 From: jonathan.borduas at caboma.com (Jonathan Borduas) Date: Tue, 14 Aug 2018 00:40:41 +0000 Subject: [vtk-developers] Nvidia rtx? In-Reply-To: <7FF56FEF-1007-4109-ABC9-704DD80EB160@spiria.com> References: <7FF56FEF-1007-4109-ABC9-704DD80EB160@spiria.com> Message-ID: This branch might interest you ;) : https://gitlab.kitware.com/demarle/paraview/commits/WIP-expose-OptiX OptiX is built on RTX. Best, Jonathan Get Outlook for iOS ________________________________ From: vtk-developers on behalf of Patrick Bergeron Sent: Monday, August 13, 2018 8:24:54 PM To: vtk-developers at vtk.org Subject: [vtk-developers] Nvidia rtx? I am sitting in at siggraph where they are talking about the rtx cards and I saw the Paraview logo as an adopting technology. Paraview ans kitware (and vtk?) moving to rtx ray tracing? Woot? Sent from my iPhone _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbergeron at spiria.com Mon Aug 13 23:11:57 2018 From: pbergeron at spiria.com (Patrick Bergeron) Date: Tue, 14 Aug 2018 03:11:57 +0000 Subject: [vtk-developers] Nvidia rtx? In-Reply-To: References: <7FF56FEF-1007-4109-ABC9-704DD80EB160@spiria.com>, Message-ID: I was having beer with folks who are involved in it. Sweet!! Sent from my iPhone On Aug 13, 2018, at 17:40, Jonathan Borduas > wrote: This branch might interest you ;) : https://gitlab.kitware.com/demarle/paraview/commits/WIP-expose-OptiX OptiX is built on RTX. Best, Jonathan Get Outlook for iOS ________________________________ From: vtk-developers > on behalf of Patrick Bergeron > Sent: Monday, August 13, 2018 8:24:54 PM To: vtk-developers at vtk.org Subject: [vtk-developers] Nvidia rtx? I am sitting in at siggraph where they are talking about the rtx cards and I saw the Paraview logo as an adopting technology. Paraview ans kitware (and vtk?) moving to rtx ray tracing? Woot? Sent from my iPhone _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbergeron at spiria.com Mon Aug 13 23:12:21 2018 From: pbergeron at spiria.com (Patrick Bergeron) Date: Tue, 14 Aug 2018 03:12:21 +0000 Subject: [vtk-developers] Nvidia rtx? In-Reply-To: References: <7FF56FEF-1007-4109-ABC9-704DD80EB160@spiria.com>, Message-ID: <99CE18B3-1CC1-4A5D-8111-8B9742A142A0@spiria.com> Any chance vtk will inherit ? Sent from my iPhone On Aug 13, 2018, at 17:40, Jonathan Borduas > wrote: This branch might interest you ;) : https://gitlab.kitware.com/demarle/paraview/commits/WIP-expose-OptiX OptiX is built on RTX. Best, Jonathan Get Outlook for iOS ________________________________ From: vtk-developers > on behalf of Patrick Bergeron > Sent: Monday, August 13, 2018 8:24:54 PM To: vtk-developers at vtk.org Subject: [vtk-developers] Nvidia rtx? I am sitting in at siggraph where they are talking about the rtx cards and I saw the Paraview logo as an adopting technology. Paraview ans kitware (and vtk?) moving to rtx ray tracing? Woot? Sent from my iPhone _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.borduas at caboma.com Mon Aug 13 23:14:16 2018 From: jonathan.borduas at caboma.com (Jonathan Borduas) Date: Tue, 14 Aug 2018 03:14:16 +0000 Subject: [vtk-developers] Nvidia rtx? In-Reply-To: <99CE18B3-1CC1-4A5D-8111-8B9742A142A0@spiria.com> References: <7FF56FEF-1007-4109-ABC9-704DD80EB160@spiria.com>, , <99CE18B3-1CC1-4A5D-8111-8B9742A142A0@spiria.com> Message-ID: Already there: https://www.vtk.org/doc/nightly/html/dir_4b00bef14f5d076e0538cdadfb4fa79b.html Get Outlook for iOS ________________________________ From: Patrick Bergeron Sent: Monday, August 13, 2018 11:12:21 PM To: Jonathan Borduas Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] Nvidia rtx? Any chance vtk will inherit ? Sent from my iPhone On Aug 13, 2018, at 17:40, Jonathan Borduas > wrote: This branch might interest you ;) : https://gitlab.kitware.com/demarle/paraview/commits/WIP-expose-OptiX OptiX is built on RTX. Best, Jonathan Get Outlook for iOS ________________________________ From: vtk-developers > on behalf of Patrick Bergeron > Sent: Monday, August 13, 2018 8:24:54 PM To: vtk-developers at vtk.org Subject: [vtk-developers] Nvidia rtx? I am sitting in at siggraph where they are talking about the rtx cards and I saw the Paraview logo as an adopting technology. Paraview ans kitware (and vtk?) moving to rtx ray tracing? Woot? Sent from my iPhone _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Tue Aug 21 13:12:33 2018 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Tue, 21 Aug 2018 13:12:33 -0400 Subject: [vtk-developers] brief CDash outage Message-ID: We will be upgrading the system that cdash.org runs on at 2:30pm EDT today (a little over an hour from now). We expect the system to be down for 15-30 minutes (or less). I'll reply to this message when the upgrade is complete. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Tue Aug 21 15:04:45 2018 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Tue, 21 Aug 2018 15:04:45 -0400 Subject: [vtk-developers] brief CDash outage In-Reply-To: References: Message-ID: This is complete. As always, please let us know if you notice anything that doesn't seem right. On Tue, Aug 21, 2018 at 1:12 PM, Zack Galbreath wrote: > We will be upgrading the system that cdash.org runs on at 2:30pm EDT > today (a little over an hour from now). We expect the system to be down > for 15-30 minutes (or less). > > I'll reply to this message when the upgrade is complete. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Thu Aug 23 05:07:10 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 23 Aug 2018 11:07:10 +0200 Subject: [vtk-developers] the New QVTKOpenGLWidget Message-ID: Hello list, If you are working on a VTK/Qt application this information should interest you. Sometime ago, a new QVTKOpenGLWidget implementation has been added to VTK, while the old one has been moved to QVTKOpenGLSimpleWidget. The last fixes for this change have just been merged, so make sure to use VTK master to test this. *1. Why is there a new widget and what does it do ?* We have been having some issues reported for the old widget, and the old widget could not support quad buffer stereo rendering by design. Has it is a needed feature in ParaView, a reimplementation was necessary. This new widget fix most of the reported issues with the old widget as well as adding stereo support. *2. Why keeping the old widget around then ?* Due to Qt limitations, this new implementation does not support very well being a native widget. But native widget are sometimes mandatory, for example within QScrollArea and QMDIArea, so the QVTKOpenGLSimpleWidget should be used when in needs of VTK rendering in the contact of Qt native widget. Also it allows users to switch back to the old widget if necessary. *3. I'm not sure what native widgets are, what should I do in my application ?* Here are the different situation : 1. Your Qt application only uses a central QVTKOpenGLWidget for rendering: -> Nothing to do, just build with last master and make sure all is working well 2. Your Qt application only uses QVTKOpenGLWidget within QScrollArea or QMDIArea, or manually set widgets to be native and you are not interested by stereo rendering. -> Change all your QVTKOpenGLWidget to QVTKOpenGLSimpleWidget and you are good to go 3. Your application uses a non-native QVTKOpenGLWidget for rendering as well as native QVTKOpenGLWidget for rendering (eg: ParaView, with the central rendering widget and the color map editor rendering widget in scroll areas) : -> Use QVTKOpenGLWidget for non-native widgets and QVTKOpenGLSimpleWidget for native ones. The later will never support stereo. *4. I followed your recommendation but I see some strange stuff/bugs/rendering issues* Even if this new class has been tested extensively and will be used in the next ParaView release, It may still contains some issues. Feel free to discuss them in this mailing list or on our gitlab . Best regards, Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Thu Aug 23 11:36:46 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 23 Aug 2018 17:36:46 +0200 Subject: [vtk-developers] Using system fonts on Windows (fontconfig equivalent?) In-Reply-To: References: Message-ID: 2017-04-11 18:43 GMT+02:00 David Lonie : > AFAIK, the only option on windows would be to load the font file > directly using vtkTextProperty::SetFontFamily(VTK_FONT_FILE) and > vtkTextProperty::SetFontFile(...). I've never heard of FontConfig > being used on Windows, but I haven't really looked into it, either. > > Good luck! Just to report back on this old post of mine. I've just built VTK with the vtkRendereringFreeTypeFontConfig module activated on Windows. I used the pre-built fontconfig binaries available at https://github.com/ShiftMediaProject/fontconfig There was one gotcha regarding updating a vtkTextProperty to match that of a QFont (such as returned by e.g. QFontDatabase::systemFont(QFontDatabase::SmallestReadableFont)). The gotcha is that QFont::family() may return a "logical" font family name such as "MS Shell Dlg 2", which needs to be mapped through the font substitution mapping in the Windows registry in order to get a "physical" font family name (such as "Tahoma") that can be passed to vtkTextProperty::SetFontFamilyAsString(..). Example shown below. Hope this might help someone else. Elvis namespace FontUtils { const static QString WindowsFontSubstitutesKey = "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\FontSubstitutes"; void updateFromQFont(vtkTextProperty *property, const QFont &font) { auto family = font.family(); #if defined(Q_OS_WIN) // On Windows, since the QFont::family() may be a "logical font" // like "MS Shell Dlg 2", we can't use it directly as parameter to // vtkTextProperty::SetFontFamilyAsString(..), but must map it // through the font substitutions in the Windows registry to // get the real font family (e.g. "Tahoma"). QSettings map(WindowsFontSubstitutesKey, QSettings::NativeFormat); family = map.value(family, family).toString(); #endif property->SetFontFamilyAsString(family.toLocal8Bit()); property->SetFontSize(font.pointSize()); property->SetBold(font.bold()); property->SetItalic(font.italic()); } > > Dave > > On Tue, Apr 11, 2017 at 4:45 AM, Elvis Stansvik > wrote: >> Hi all, >> >> Cross-posting since I'm not sure if vtkusers@ or vtk-developers@ is >> most appropriate for this. >> >> On Linux, I'm using the vtkRendereringFreeTypeFontConfig module, so >> that I can use system fonts (e.g. for charts labels et.c). The goal is >> to make VTK fonts match those used by Qt, so I'm using >> QFontDatabase::system(...) to query for the user's preferred font, and >> then use that in my VTK code. This is all working quite well. >> >> I'm now porting the application to Windows. Does VTK have any support >> for loading system fonts on Windows? Something similar to the >> vtkRendereringFreeTypeFontConfig, but for whatever font backend >> Windows uses? >> >> If not, has anyone had luck in building fontconfig for Windows, and >> using the vtkRendereringFreeTypeFontConfig module there? (I'm not even >> sure if fontconfig has support for hooking into Windows' font backend, >> so this may not be a solution at all). >> >> Many thanks in advance, >> Elvis >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> From elvis.stansvik at orexplore.com Fri Aug 24 05:46:35 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 24 Aug 2018 11:46:35 +0200 Subject: [vtk-developers] [vtkusers] the New QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2018-08-23 11:07 GMT+02:00 Mathieu Westphal : > Hello list, > > If you are working on a VTK/Qt application this information should interest > you. > Sometime ago, a new QVTKOpenGLWidget implementation has been added to VTK, > while the old one has been moved to QVTKOpenGLSimpleWidget. > The last fixes for this change have just been merged, so make sure to use > VTK master to test this. > > 1. Why is there a new widget and what does it do ? > We have been having some issues reported for the old widget, and the old > widget could not support quad buffer stereo rendering by design. > Has it is a needed feature in ParaView, a reimplementation was necessary. > This new widget fix most of the reported issues with the old widget as well > as adding stereo support. > > 2. Why keeping the old widget around then ? > Due to Qt limitations, this new implementation does not support very well > being a native widget. > But native widget are sometimes mandatory, for example within QScrollArea > and QMDIArea, so the QVTKOpenGLSimpleWidget should be used when in needs of > VTK rendering in the contact of Qt native widget. > > Also it allows users to switch back to the old widget if necessary. > > 3. I'm not sure what native widgets are, what should I do in my application > ? > > Here are the different situation : > > Your Qt application only uses a central QVTKOpenGLWidget for rendering: > -> Nothing to do, just build with last master and make sure all is working > well > Your Qt application only uses QVTKOpenGLWidget within QScrollArea or > QMDIArea, or manually set widgets to be native and you are not interested by > stereo rendering. > -> Change all your QVTKOpenGLWidget to QVTKOpenGLSimpleWidget and you are > good to go > Your application uses a non-native QVTKOpenGLWidget for rendering as well as > native QVTKOpenGLWidget for rendering (eg: ParaView, with the central > rendering widget and the color map editor rendering widget in scroll areas) > : > -> Use QVTKOpenGLWidget for non-native widgets and QVTKOpenGLSimpleWidget > for native ones. The later will never support stereo. > > > 4. I followed your recommendation but I see some strange > stuff/bugs/rendering issues > Even if this new class has been tested extensively and will be used in the > next ParaView release, It may still contains some issues. Feel free to > discuss them in this mailing list or on our gitlab. Thanks for the update/advice Mathieu. I have an old semi-alive merge request against the old QVTKOpenGLWidget (now QVTKOpenGLSimpleWidget): https://gitlab.kitware.com/vtk/vtk/merge_requests/3973 I could use some advice on what to do with it. It fixes an issue that I believe is solved in the new one (fractional DPI scale factors). Do you wish that I update the patch so that it applies to the QVTKOpenGLSimpleWidget, which might still have the problem? (haven't checked). Also, I'd like to take the opportunity to ask: Anyone know when a first RC of VTK 9.0.0 might be coming (and final release)? I'm anxious to get fractional DPI scaling working well in our application, because we're getting customer bug reports for users on Windows, where it's quite common with laptops configured with 150% and 250% scaling. I don't think we're dependant upon native widgets, so we should be moving to the new widget. But we try to only ship with released versions of VTK (sometimes we've used RCs, and in rare cases VTK master). Cheers, Elvis > > Best regards, > > Mathieu Westphal > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtkusers > From hahnse at ornl.gov Fri Aug 24 18:51:53 2018 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Fri, 24 Aug 2018 22:51:53 +0000 Subject: [vtk-developers] Integer overflow when clipping large volumes Message-ID: <5EFFE21F-F29B-4C30-92D3-6EE8C1203231@ornl.gov> I encountered a segmentation fault when attempting to clip a stack of tiffs (vtkImageData) in ParaView and, using the undefined behavior sanitizer, tracked it down to integer overflow in vtkTableBasedClipDataSet. Changing several variables from int to vtkIdType seems to correct the problem. I opened a merge request with these changes and a python file to reproduce the issue. The primary contributor to vtkTableBasedClipDataSet.cxx isn?t on the GitLab site, so I?m not sure who to tag. Is someone else interested in reviewing it? https://gitlab.kitware.com/vtk/vtk/merge_requests/4620 Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Fri Aug 24 19:11:14 2018 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Fri, 24 Aug 2018 19:11:14 -0400 Subject: [vtk-developers] Integer overflow when clipping large volumes In-Reply-To: <5EFFE21F-F29B-4C30-92D3-6EE8C1203231@ornl.gov> References: <5EFFE21F-F29B-4C30-92D3-6EE8C1203231@ornl.gov> Message-ID: Steven, Thanks for your contribution! Your change makes sense. I'll merge it when the tests finish. Dan On Fri, Aug 24, 2018 at 7:01 PM Hahn, Steven E. wrote: > I encountered a segmentation fault when attempting to clip a stack of > tiffs (vtkImageData) in ParaView and, using the undefined behavior > sanitizer, tracked it down to integer overflow in vtkTableBasedClipDataSet. > Changing several variables from int to vtkIdType seems to correct the > problem. > > > > I opened a merge request with these changes and a python file to reproduce > the issue. The primary contributor to vtkTableBasedClipDataSet.cxx isn?t on > the GitLab site, so I?m not sure who to tag. Is someone else interested in > reviewing it? > > > > https://gitlab.kitware.com/vtk/vtk/merge_requests/4620 > > > > Steven > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Fri Aug 24 20:34:02 2018 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Fri, 24 Aug 2018 20:34:02 -0400 Subject: [vtk-developers] Integer overflow when clipping large volumes In-Reply-To: References: <5EFFE21F-F29B-4C30-92D3-6EE8C1203231@ornl.gov> Message-ID: Its merged. On Fri, Aug 24, 2018 at 7:11 PM Dan Lipsa wrote: > Steven, > Thanks for your contribution! Your change makes sense. I'll merge it when > the tests finish. > > Dan > > > On Fri, Aug 24, 2018 at 7:01 PM Hahn, Steven E. wrote: > >> I encountered a segmentation fault when attempting to clip a stack of >> tiffs (vtkImageData) in ParaView and, using the undefined behavior >> sanitizer, tracked it down to integer overflow in vtkTableBasedClipDataSet. >> Changing several variables from int to vtkIdType seems to correct the >> problem. >> >> >> >> I opened a merge request with these changes and a python file to >> reproduce the issue. The primary contributor to >> vtkTableBasedClipDataSet.cxx isn?t on the GitLab site, so I?m not sure who >> to tag. Is someone else interested in reviewing it? >> >> >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/4620 >> >> >> >> Steven >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Sat Aug 25 07:01:19 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 25 Aug 2018 13:01:19 +0200 Subject: [vtk-developers] Slow resize of vtkContextView (on Win 10) Message-ID: Hi all, As I was debugging DPI issues on Windows today, I noticed an unrelated thing. Resizing a vtkContextView (in this case, containing a vtkChartXY) is very (!) slow. See the following screen recording where I resize the window: https://drive.google.com/open?id=1pOKuDjT4IwE54xIRQoYni5-A2PUeZtbL The recording itself makes it look a little worse than it is, but it's not far off from the actual experience. This was on Win 10, with VTK 8.1.1, OpenGL 2 backend, Qt 5.11.1. The vtkContextView was in a QVTKOpenGLWidget. I know that accomplishing smooth resizing of GL windows is non-trivial, but should it really be this bad? It makes it impossible to build Qt/VTK applications that resize smoothly. Best regards, Elvis From elvis.stansvik at orexplore.com Sat Aug 25 07:03:33 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 25 Aug 2018 13:03:33 +0200 Subject: [vtk-developers] Slow resize of vtkContextView (on Win 10) In-Reply-To: References: Message-ID: I don't think the code matters much, but here it is (it was the beginning of a test case for something else, so has some unrelated things in it): #include #include #include #include #include #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { vtkFreeTypeTools::GetInstance()->ForceCompiledFontsOff(); QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); QApplication app(argc, argv); auto window = vtkSmartPointer::New(); auto widget = new QVTKOpenGLWidget(); widget->SetRenderWindow(window); qDebug() << "Setting DPI to" << widget->logicalDpiX(); window->SetDPI(widget->logicalDpiX()); auto chart = vtkSmartPointer::New(); chart->AddPlot(vtkChart::LINE); chart->GetAxis(vtkAxis::BOTTOM)->SetVisible(false); for (auto axisId : { vtkAxis::LEFT, vtkAxis::BOTTOM }) { auto axis = chart->GetAxis(axisId); auto labelProperty = axis->GetLabelProperties(); labelProperty->SetFontFamilyAsString("Tahoma"); labelProperty->SetFontSize(8); auto titleProperty = axis->GetTitleProperties(); titleProperty->SetFontFamilyAsString("Tahoma"); titleProperty->SetFontSize(8); } auto view = vtkSmartPointer::New(); view->GetRenderer()->SetBackground(1.0, 1.0, 1.0); view->SetRenderWindow(window.Get()); view->GetScene()->AddItem(chart); widget->show(); return app.exec(); } Elvis 2018-08-25 13:01 GMT+02:00 Elvis Stansvik : > Hi all, > > As I was debugging DPI issues on Windows today, I noticed an unrelated thing. > > Resizing a vtkContextView (in this case, containing a vtkChartXY) is > very (!) slow. > > See the following screen recording where I resize the window: > > https://drive.google.com/open?id=1pOKuDjT4IwE54xIRQoYni5-A2PUeZtbL > > The recording itself makes it look a little worse than it is, but it's > not far off from the actual experience. > > This was on Win 10, with VTK 8.1.1, OpenGL 2 backend, Qt 5.11.1. The > vtkContextView was in a QVTKOpenGLWidget. > > I know that accomplishing smooth resizing of GL windows is > non-trivial, but should it really be this bad? It makes it impossible > to build Qt/VTK applications that resize smoothly. > > Best regards, > Elvis From elvis.stansvik at orexplore.com Sat Aug 25 07:06:39 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 25 Aug 2018 13:06:39 +0200 Subject: [vtk-developers] Slow resize of vtkContextView (on Win 10) In-Reply-To: References: Message-ID: 2018-08-25 13:01 GMT+02:00 Elvis Stansvik : > Hi all, > > As I was debugging DPI issues on Windows today, I noticed an unrelated thing. > > Resizing a vtkContextView (in this case, containing a vtkChartXY) is > very (!) slow. > > See the following screen recording where I resize the window: > > https://drive.google.com/open?id=1pOKuDjT4IwE54xIRQoYni5-A2PUeZtbL > > The recording itself makes it look a little worse than it is, but it's > not far off from the actual experience. > > This was on Win 10, with VTK 8.1.1, OpenGL 2 backend, Qt 5.11.1. The > vtkContextView was in a QVTKOpenGLWidget. More info: The computer was a Thinkpad X1 Carbon with Intel UHD Graphics 620. Elvis > > I know that accomplishing smooth resizing of GL windows is > non-trivial, but should it really be this bad? It makes it impossible > to build Qt/VTK applications that resize smoothly. > > Best regards, > Elvis From elvis.stansvik at orexplore.com Sat Aug 25 08:04:01 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 25 Aug 2018 14:04:01 +0200 Subject: [vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache Message-ID: Hi Marcus and all, Marcus, I found this (very) old post of yours where you linked to a Gerrit change in which (I believe) you fixed a problem with the string texture cache of vtkOpenGLContextDevice2D not being invalidated when the font size, color et.c. changes: https://www.vtk.org/pipermail/vtkusers/2011-November/071067.html The reason I'm asking is that I'm suspecting that, since the DPI is taken into account when these textures are created, the cache should be invalidated also when the DPI of the render window changes? I'm in a situation now where I'm trying to make our application react well to DPI changes, but a simple SetDPI on the render window, the axis label text sizes do not change. So I'm faced with perhaps having to recreate the entire chart when the DPI changes. Does it sound plausible that it could be the texture cache mentioned in that old thread? Many thanks in advance, Elvis From elvis.stansvik at orexplore.com Sat Aug 25 08:45:55 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 25 Aug 2018 14:45:55 +0200 Subject: [vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache In-Reply-To: References: Message-ID: 2018-08-25 14:04 GMT+02:00 Elvis Stansvik : > Hi Marcus and all, > > Marcus, I found this (very) old post of yours where you linked to a > Gerrit change in which (I believe) you fixed a problem with the string > texture cache of vtkOpenGLContextDevice2D not being invalidated when > the font size, color et.c. changes: > > https://www.vtk.org/pipermail/vtkusers/2011-November/071067.html > > The reason I'm asking is that I'm suspecting that, since the DPI is > taken into account when these textures are created, the cache should > be invalidated also when the DPI of the render window changes? > > I'm in a situation now where I'm trying to make our application react > well to DPI changes, but a simple SetDPI on the render window, the > axis label text sizes do not change. So I'm faced with perhaps having > to recreate the entire chart when the DPI changes. > > Does it sound plausible that it could be the texture cache mentioned > in that old thread? Nevermind, I've just discovered that something is mysteriously re-setting the DPI to 72 after I set it. I'll have to investigate that issue instead. Elvis > > Many thanks in advance, > Elvis From elvis.stansvik at orexplore.com Sat Aug 25 09:05:54 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 25 Aug 2018 15:05:54 +0200 Subject: [vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache In-Reply-To: References: Message-ID: 2018-08-25 14:45 GMT+02:00 Elvis Stansvik : > 2018-08-25 14:04 GMT+02:00 Elvis Stansvik : >> Hi Marcus and all, >> >> Marcus, I found this (very) old post of yours where you linked to a >> Gerrit change in which (I believe) you fixed a problem with the string >> texture cache of vtkOpenGLContextDevice2D not being invalidated when >> the font size, color et.c. changes: >> >> https://www.vtk.org/pipermail/vtkusers/2011-November/071067.html >> >> The reason I'm asking is that I'm suspecting that, since the DPI is >> taken into account when these textures are created, the cache should >> be invalidated also when the DPI of the render window changes? >> >> I'm in a situation now where I'm trying to make our application react >> well to DPI changes, but a simple SetDPI on the render window, the >> axis label text sizes do not change. So I'm faced with perhaps having >> to recreate the entire chart when the DPI changes. >> >> Does it sound plausible that it could be the texture cache mentioned >> in that old thread? > > Nevermind, I've just discovered that something is mysteriously > re-setting the DPI to 72 after I set it. > > I'll have to investigate that issue instead. OK, I think there's some bug related to how setEnableHiDPI works (and the fact that it's called in recreateFBO). void QVTKOpenGLWidget::setEnableHiDPI(bool enable) { this->EnableHiDPI = enable; if (this->RenderWindow) { if (this->OriginalDPI == 0) { this->OriginalDPI = this->RenderWindow->GetDPI(); } if (this->EnableHiDPI) { this->RenderWindow->SetDPI(this->OriginalDPI * this->devicePixelRatio()); } else { this->RenderWindow->SetDPI(this->OriginalDPI); } } } So the first time setEnableHiDPI is called (and there's a render window present), the DPI at that time is cached in this->OriginalDPI, and that DPI is used for subsequent calls. I don't see how this can work with runtime DPI changes (when the user calls SetDPI to set the appropriate DPI)? Elvis > > Elvis > >> >> Many thanks in advance, >> Elvis From elvis.stansvik at orexplore.com Sat Aug 25 09:33:45 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 25 Aug 2018 15:33:45 +0200 Subject: [vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache In-Reply-To: References: Message-ID: 2018-08-25 15:05 GMT+02:00 Elvis Stansvik : > 2018-08-25 14:45 GMT+02:00 Elvis Stansvik : >> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik : >>> Hi Marcus and all, >>> >>> Marcus, I found this (very) old post of yours where you linked to a >>> Gerrit change in which (I believe) you fixed a problem with the string >>> texture cache of vtkOpenGLContextDevice2D not being invalidated when >>> the font size, color et.c. changes: >>> >>> https://www.vtk.org/pipermail/vtkusers/2011-November/071067.html >>> >>> The reason I'm asking is that I'm suspecting that, since the DPI is >>> taken into account when these textures are created, the cache should >>> be invalidated also when the DPI of the render window changes? >>> >>> I'm in a situation now where I'm trying to make our application react >>> well to DPI changes, but a simple SetDPI on the render window, the >>> axis label text sizes do not change. So I'm faced with perhaps having >>> to recreate the entire chart when the DPI changes. >>> >>> Does it sound plausible that it could be the texture cache mentioned >>> in that old thread? >> >> Nevermind, I've just discovered that something is mysteriously >> re-setting the DPI to 72 after I set it. >> >> I'll have to investigate that issue instead. > > OK, I think there's some bug related to how setEnableHiDPI works (and > the fact that it's called in recreateFBO). > > void QVTKOpenGLWidget::setEnableHiDPI(bool enable) > { > this->EnableHiDPI = enable; > > if (this->RenderWindow) > { > if (this->OriginalDPI == 0) > { > this->OriginalDPI = this->RenderWindow->GetDPI(); > } > if (this->EnableHiDPI) > { > this->RenderWindow->SetDPI(this->OriginalDPI * this->devicePixelRatio()); > } > else > { > this->RenderWindow->SetDPI(this->OriginalDPI); > } > } > } > > So the first time setEnableHiDPI is called (and there's a render > window present), the DPI at that time is cached in this->OriginalDPI, > and that DPI is used for subsequent calls. > > I don't see how this can work with runtime DPI changes (when the user > calls SetDPI to set the appropriate DPI)? I can work around the problem by re-setting OriginalDPI to 0 directly after I call SetDPI on DPI changes (I'm subclassing QVTKOpenGLWidget, so have access to it), but I doubt this was intended? Elvis > > Elvis > >> >> Elvis >> >>> >>> Many thanks in advance, >>> Elvis From marcus.hanwell at kitware.com Mon Aug 27 12:01:53 2018 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 27 Aug 2018 12:01:53 -0400 Subject: [vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache In-Reply-To: References: Message-ID: On Sat, Aug 25, 2018 at 9:33 AM Elvis Stansvik wrote: > 2018-08-25 15:05 GMT+02:00 Elvis Stansvik : > > 2018-08-25 14:45 GMT+02:00 Elvis Stansvik >: > >> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik >: > >>> Marcus, I found this (very) old post of yours where you linked to a > >>> Gerrit change in which (I believe) you fixed a problem with the string > >>> texture cache of vtkOpenGLContextDevice2D not being invalidated when > >>> the font size, color et.c. changes: > >>> > >>> https://www.vtk.org/pipermail/vtkusers/2011-November/071067.html > >>> > >>> The reason I'm asking is that I'm suspecting that, since the DPI is > >>> taken into account when these textures are created, the cache should > >>> be invalidated also when the DPI of the render window changes? > >>> > >>> I'm in a situation now where I'm trying to make our application react > >>> well to DPI changes, but a simple SetDPI on the render window, the > >>> axis label text sizes do not change. So I'm faced with perhaps having > >>> to recreate the entire chart when the DPI changes. > >>> > >>> Does it sound plausible that it could be the texture cache mentioned > >>> in that old thread? > >> > >> Nevermind, I've just discovered that something is mysteriously > >> re-setting the DPI to 72 after I set it. > >> > >> I'll have to investigate that issue instead. > > > > So the first time setEnableHiDPI is called (and there's a render > > window present), the DPI at that time is cached in this->OriginalDPI, > > and that DPI is used for subsequent calls. > > > > I don't see how this can work with runtime DPI changes (when the user > > calls SetDPI to set the appropriate DPI)? > > I can work around the problem by re-setting OriginalDPI to 0 directly > after I call SetDPI on DPI changes (I'm subclassing QVTKOpenGLWidget, > so have access to it), but I doubt this was intended? > That is an old issue, I think we got it fixed, but I am not sure whether the font cache would be using the DPI as most of that work predated all this. I will try and take a look, but it is many years since I last looked at that code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcfr at kitware.com Mon Aug 27 18:12:11 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 27 Aug 2018 18:12:11 -0400 Subject: [vtk-developers] the New QVTKOpenGLWidget In-Reply-To: References: Message-ID: Hi All, To follow up on Mathieu email, we are in in the process of integrating this merge request [1] (and the equivalent in paraview [2]) that will add/rename the following classes: * QVTKOpenGLAlienWidget (equivalent to QVTKOpenGLWidget class described in the previous email) * QVTKOpenGLNativeWidget (equivalent to QVTKOpenGLSimpleWidget class described in the previous email) * QVTKOpenGLWidget will: - behave as it was before the introduction of the "new QVTKOpenGLWidget" and will instead derive from QVTKOpenGLNativeWidget. - only be available if VTK_LEGACY_REMOVE is OFF - will most likely be removed in VTK 10 We anticipate that this clearer naming convention will facilitate update of user code. Let us know what you think, Thanks Jc [1] https://gitlab.kitware.com/vtk/vtk/merge_requests/4625 [2] https://gitlab.kitware.com/paraview/paraview/merge_requests/2693 On Thu, Aug 23, 2018 at 5:07 AM Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Hello list, > > If you are working on a VTK/Qt application this information should > interest you. > Sometime ago, a new QVTKOpenGLWidget implementation has been added to VTK, > while the old one has been moved to QVTKOpenGLSimpleWidget. > The last fixes for this change have just been merged, so make sure to use > VTK master to test this. > > *1. Why is there a new widget and what does it do ?* > We have been having some issues reported for the old widget, and the old > widget could not support quad buffer stereo rendering by design. > Has it is a needed feature in ParaView, a reimplementation was necessary. > This new widget fix most of the reported issues with the old widget as well > as adding stereo support. > > *2. Why keeping the old widget around then ?* > Due to Qt limitations, this new implementation does not support very well > being a native widget. > But native widget are sometimes mandatory, for example within QScrollArea > and QMDIArea, so the QVTKOpenGLSimpleWidget should be used when in needs of > VTK rendering in the contact of Qt native widget. > > Also it allows users to switch back to the old widget if necessary. > > *3. I'm not sure what native widgets are, what should I do in my > application ?* > > Here are the different situation : > > 1. Your Qt application only uses a central QVTKOpenGLWidget for > rendering: > -> Nothing to do, just build with last master and make sure all is > working well > 2. Your Qt application only uses QVTKOpenGLWidget within QScrollArea > or QMDIArea, or manually set widgets to be native and you are not > interested by stereo rendering. > -> Change all your QVTKOpenGLWidget to QVTKOpenGLSimpleWidget and you > are good to go > 3. Your application uses a non-native QVTKOpenGLWidget for rendering > as well as native QVTKOpenGLWidget for rendering (eg: ParaView, with the > central rendering widget and the color map editor rendering widget in > scroll areas) : > -> Use QVTKOpenGLWidget for non-native widgets and > QVTKOpenGLSimpleWidget for native ones. The later will never support stereo. > > > *4. I followed your recommendation but I see some strange > stuff/bugs/rendering issues* > Even if this new class has been tested extensively and will be used in the > next ParaView release, It may still contains some issues. Feel free to > discuss them in this mailing list or on our gitlab > . > > Best regards, > > Mathieu Westphal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue Aug 28 01:23:30 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 28 Aug 2018 07:23:30 +0200 Subject: [vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache In-Reply-To: References: Message-ID: 2018-08-27 18:01 GMT+02:00 Marcus D. Hanwell : > On Sat, Aug 25, 2018 at 9:33 AM Elvis Stansvik > wrote: >> >> 2018-08-25 15:05 GMT+02:00 Elvis Stansvik : >> > 2018-08-25 14:45 GMT+02:00 Elvis Stansvik >> > : >> >> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik >> >> : >> >>> Marcus, I found this (very) old post of yours where you linked to a >> >>> Gerrit change in which (I believe) you fixed a problem with the string >> >>> texture cache of vtkOpenGLContextDevice2D not being invalidated when >> >>> the font size, color et.c. changes: >> >>> >> >>> https://www.vtk.org/pipermail/vtkusers/2011-November/071067.html >> >>> >> >>> The reason I'm asking is that I'm suspecting that, since the DPI is >> >>> taken into account when these textures are created, the cache should >> >>> be invalidated also when the DPI of the render window changes? >> >>> >> >>> I'm in a situation now where I'm trying to make our application react >> >>> well to DPI changes, but a simple SetDPI on the render window, the >> >>> axis label text sizes do not change. So I'm faced with perhaps having >> >>> to recreate the entire chart when the DPI changes. >> >>> >> >>> Does it sound plausible that it could be the texture cache mentioned >> >>> in that old thread? >> >> >> >> Nevermind, I've just discovered that something is mysteriously >> >> re-setting the DPI to 72 after I set it. >> >> >> >> I'll have to investigate that issue instead. >> > >> > So the first time setEnableHiDPI is called (and there's a render >> > window present), the DPI at that time is cached in this->OriginalDPI, >> > and that DPI is used for subsequent calls. >> > >> > I don't see how this can work with runtime DPI changes (when the user >> > calls SetDPI to set the appropriate DPI)? >> >> I can work around the problem by re-setting OriginalDPI to 0 directly >> after I call SetDPI on DPI changes (I'm subclassing QVTKOpenGLWidget, >> so have access to it), but I doubt this was intended? > > > That is an old issue, I think we got it fixed, but I am not sure whether the > font cache would be using the DPI as most of that work predated all this. I > will try and take a look, but it is many years since I last looked at that > code. Thanks. Just to clarify: With the hack above, it works fine - the text rendering respects the set DPI. What I don't understand is the logic in setEnableHiDPI, because the way it is written, it means that each time setEnableHiDPI is called during runtime, the DPI will be re-set to whatever it was when setEnableHiDPI was called the first time. And when using QVTKOpenGLWidget, setEnableHiDPI is called on each recreateFBO call. So it seems to me a user can never call SetDPI on the render window of a QVTKOpenGLWidget and have it "stick". It will be re-set behind the scenes :/ Elvis From elvis.stansvik at orexplore.com Tue Aug 28 01:28:23 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 28 Aug 2018 07:28:23 +0200 Subject: [vtk-developers] [vtkusers] the New QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2018-08-28 0:12 GMT+02:00 Jean-Christophe Fillion-Robin : > Hi All, > > To follow up on Mathieu email, we are in in the process of integrating this > merge request [1] (and the equivalent in paraview [2]) that will add/rename > the following classes: > > * QVTKOpenGLAlienWidget (equivalent to QVTKOpenGLWidget class described in > the previous email) > > * QVTKOpenGLNativeWidget (equivalent to QVTKOpenGLSimpleWidget class > described in the previous email) > > * QVTKOpenGLWidget will: > - behave as it was before the introduction of the "new QVTKOpenGLWidget" > and will instead derive from QVTKOpenGLNativeWidget. > - only be available if VTK_LEGACY_REMOVE is OFF > - will most likely be removed in VTK 10 > > > We anticipate that this clearer naming convention will facilitate update of > user code. > > Let us know what you think, I think this naming is the best one possible, unless it's somehow possible to make a widget that will work well in both scenarios of course :) Much better naming than the "Simple" suffix, so +1. Elvis > > Thanks > Jc > > > [1] https://gitlab.kitware.com/vtk/vtk/merge_requests/4625 > [2] https://gitlab.kitware.com/paraview/paraview/merge_requests/2693 > > > > > > > > > On Thu, Aug 23, 2018 at 5:07 AM Mathieu Westphal > wrote: >> >> Hello list, >> >> If you are working on a VTK/Qt application this information should >> interest you. >> Sometime ago, a new QVTKOpenGLWidget implementation has been added to VTK, >> while the old one has been moved to QVTKOpenGLSimpleWidget. >> The last fixes for this change have just been merged, so make sure to use >> VTK master to test this. >> >> 1. Why is there a new widget and what does it do ? >> We have been having some issues reported for the old widget, and the old >> widget could not support quad buffer stereo rendering by design. >> Has it is a needed feature in ParaView, a reimplementation was necessary. >> This new widget fix most of the reported issues with the old widget as well >> as adding stereo support. >> >> 2. Why keeping the old widget around then ? >> Due to Qt limitations, this new implementation does not support very well >> being a native widget. >> But native widget are sometimes mandatory, for example within QScrollArea >> and QMDIArea, so the QVTKOpenGLSimpleWidget should be used when in needs of >> VTK rendering in the contact of Qt native widget. >> >> Also it allows users to switch back to the old widget if necessary. >> >> 3. I'm not sure what native widgets are, what should I do in my >> application ? >> >> Here are the different situation : >> >> Your Qt application only uses a central QVTKOpenGLWidget for rendering: >> -> Nothing to do, just build with last master and make sure all is working >> well >> Your Qt application only uses QVTKOpenGLWidget within QScrollArea or >> QMDIArea, or manually set widgets to be native and you are not interested by >> stereo rendering. >> -> Change all your QVTKOpenGLWidget to QVTKOpenGLSimpleWidget and you are >> good to go >> Your application uses a non-native QVTKOpenGLWidget for rendering as well >> as native QVTKOpenGLWidget for rendering (eg: ParaView, with the central >> rendering widget and the color map editor rendering widget in scroll areas) >> : >> -> Use QVTKOpenGLWidget for non-native widgets and QVTKOpenGLSimpleWidget >> for native ones. The later will never support stereo. >> >> >> 4. I followed your recommendation but I see some strange >> stuff/bugs/rendering issues >> Even if this new class has been tested extensively and will be used in the >> next ParaView release, It may still contains some issues. Feel free to >> discuss them in this mailing list or on our gitlab. >> >> Best regards, >> >> Mathieu Westphal > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtkusers > From marcus.hanwell at kitware.com Tue Aug 28 10:14:39 2018 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 28 Aug 2018 10:14:39 -0400 Subject: [vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache In-Reply-To: References: Message-ID: On Tue, Aug 28, 2018 at 1:23 AM Elvis Stansvik wrote: > 2018-08-27 18:01 GMT+02:00 Marcus D. Hanwell : > > On Sat, Aug 25, 2018 at 9:33 AM Elvis Stansvik > > wrote: > >> > >> 2018-08-25 15:05 GMT+02:00 Elvis Stansvik >: > >> > 2018-08-25 14:45 GMT+02:00 Elvis Stansvik > >> > : > >> >> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik > >> >> : > >> >>> Marcus, I found this (very) old post of yours where you linked to a > >> >>> Gerrit change in which (I believe) you fixed a problem with the > string > >> >>> texture cache of vtkOpenGLContextDevice2D not being invalidated when > >> >>> the font size, color et.c. changes: > >> >>> > >> >>> > https://www.vtk.org/pipermail/vtkusers/2011-November/071067.html > >> >>> > >> >>> The reason I'm asking is that I'm suspecting that, since the DPI is > >> >>> taken into account when these textures are created, the cache should > >> >>> be invalidated also when the DPI of the render window changes? > >> >>> > >> >>> I'm in a situation now where I'm trying to make our application > react > >> >>> well to DPI changes, but a simple SetDPI on the render window, the > >> >>> axis label text sizes do not change. So I'm faced with perhaps > having > >> >>> to recreate the entire chart when the DPI changes. > >> >>> > >> >>> Does it sound plausible that it could be the texture cache mentioned > >> >>> in that old thread? > >> >> > >> >> Nevermind, I've just discovered that something is mysteriously > >> >> re-setting the DPI to 72 after I set it. > >> >> > >> >> I'll have to investigate that issue instead. > >> > > >> > So the first time setEnableHiDPI is called (and there's a render > >> > window present), the DPI at that time is cached in this->OriginalDPI, > >> > and that DPI is used for subsequent calls. > >> > > >> > I don't see how this can work with runtime DPI changes (when the user > >> > calls SetDPI to set the appropriate DPI)? > >> > >> I can work around the problem by re-setting OriginalDPI to 0 directly > >> after I call SetDPI on DPI changes (I'm subclassing QVTKOpenGLWidget, > >> so have access to it), but I doubt this was intended? > > > > > > That is an old issue, I think we got it fixed, but I am not sure whether > the > > font cache would be using the DPI as most of that work predated all > this. I > > will try and take a look, but it is many years since I last looked at > that > > code. > > Thanks. Just to clarify: With the hack above, it works fine - the text > rendering respects the set DPI. > > What I don't understand is the logic in setEnableHiDPI, because the > way it is written, it means that each time setEnableHiDPI is called > during runtime, the DPI will be re-set to whatever it was when > setEnableHiDPI was called the first time. And when using > QVTKOpenGLWidget, setEnableHiDPI is called on each recreateFBO call. > So it seems to me a user can never call SetDPI on the render window of > a QVTKOpenGLWidget and have it "stick". It will be re-set behind the > scenes :/ > > I was just looking at this yesterday, and agree with your diagnosis. I had overridden void setEnableHiDPI(bool enable) but the signature changed, and now don't see a good way to do that. I am also looking into font scaling issues, at least on Linux with a 4k high DPI display the chart fonts look tiny. I will try and do some more testing, the fonts in Qt look fine so it would appear to be an issue with our rendering somewhere. Thanks, Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Wed Aug 29 01:58:00 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 29 Aug 2018 07:58:00 +0200 Subject: [vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache In-Reply-To: References: Message-ID: 2018-08-28 16:14 GMT+02:00 Marcus D. Hanwell : > On Tue, Aug 28, 2018 at 1:23 AM Elvis Stansvik > wrote: >> >> 2018-08-27 18:01 GMT+02:00 Marcus D. Hanwell : >> > On Sat, Aug 25, 2018 at 9:33 AM Elvis Stansvik >> > wrote: >> >> >> >> 2018-08-25 15:05 GMT+02:00 Elvis Stansvik >> >> : >> >> > 2018-08-25 14:45 GMT+02:00 Elvis Stansvik >> >> > : >> >> >> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik >> >> >> : >> >> >>> Marcus, I found this (very) old post of yours where you linked to a >> >> >>> Gerrit change in which (I believe) you fixed a problem with the >> >> >>> string >> >> >>> texture cache of vtkOpenGLContextDevice2D not being invalidated >> >> >>> when >> >> >>> the font size, color et.c. changes: >> >> >>> >> >> >>> >> >> >>> https://www.vtk.org/pipermail/vtkusers/2011-November/071067.html >> >> >>> >> >> >>> The reason I'm asking is that I'm suspecting that, since the DPI is >> >> >>> taken into account when these textures are created, the cache >> >> >>> should >> >> >>> be invalidated also when the DPI of the render window changes? >> >> >>> >> >> >>> I'm in a situation now where I'm trying to make our application >> >> >>> react >> >> >>> well to DPI changes, but a simple SetDPI on the render window, the >> >> >>> axis label text sizes do not change. So I'm faced with perhaps >> >> >>> having >> >> >>> to recreate the entire chart when the DPI changes. >> >> >>> >> >> >>> Does it sound plausible that it could be the texture cache >> >> >>> mentioned >> >> >>> in that old thread? >> >> >> >> >> >> Nevermind, I've just discovered that something is mysteriously >> >> >> re-setting the DPI to 72 after I set it. >> >> >> >> >> >> I'll have to investigate that issue instead. >> >> > >> >> > So the first time setEnableHiDPI is called (and there's a render >> >> > window present), the DPI at that time is cached in this->OriginalDPI, >> >> > and that DPI is used for subsequent calls. >> >> > >> >> > I don't see how this can work with runtime DPI changes (when the user >> >> > calls SetDPI to set the appropriate DPI)? >> >> >> >> I can work around the problem by re-setting OriginalDPI to 0 directly >> >> after I call SetDPI on DPI changes (I'm subclassing QVTKOpenGLWidget, >> >> so have access to it), but I doubt this was intended? >> > >> > >> > That is an old issue, I think we got it fixed, but I am not sure whether >> > the >> > font cache would be using the DPI as most of that work predated all >> > this. I >> > will try and take a look, but it is many years since I last looked at >> > that >> > code. >> >> Thanks. Just to clarify: With the hack above, it works fine - the text >> rendering respects the set DPI. >> >> What I don't understand is the logic in setEnableHiDPI, because the >> way it is written, it means that each time setEnableHiDPI is called >> during runtime, the DPI will be re-set to whatever it was when >> setEnableHiDPI was called the first time. And when using >> QVTKOpenGLWidget, setEnableHiDPI is called on each recreateFBO call. >> So it seems to me a user can never call SetDPI on the render window of >> a QVTKOpenGLWidget and have it "stick". It will be re-set behind the >> scenes :/ >> > I was just looking at this yesterday, and agree with your diagnosis. I had > overridden void setEnableHiDPI(bool enable) but the signature changed, and > now don't see a good way to do that. I am also looking into font scaling > issues, at least on Linux with a 4k high DPI display the chart fonts look > tiny. I will try and do some more testing, the fonts in Qt look fine so it > would appear to be an issue with our rendering somewhere. Alright. The fonts looking tiny on Linux/4k is probably just a matter of the text rendering not respecting devicePixelRatioF(). I'm guessing the machine is running with QT_SCREEN_SCALE_FACTORS or Qt::AA_EnableHighDpiScaling set, to enable Qt's built-in pixel scaling?. In my case, I was testing this on Windows with it's screen scaling option set to 200%. But the Windows "screen scaling" is really just about changing fonts/DPI/layouts AFAIK, and will not affect what the Qt devicePixelRatioF() API reports. So it was two different cases. I just wanted it to respect the DPI of the screen (which it seems to do), while you want it to respect any device pixel ratio in effect. I would like that as well of course, because next on my list after fixing Windows HiDPI issues is Mac/Linux :) Making a Qt app work well on HiDPI on all three platforms, and in all events (changing resolution, screen scaling, DPI) is really non-trivial I've discovered :/ On Windows the situation is even worse, because if you run with Qt's pixel-based scaling turned off (as is recommended for new apps in the Qt docs), then there even seems to be built-in controls in Qt that don't work well in a mixed-DPI setup (extended desktop on Windows), at least not with the Win 10 Qt style, so you're sort of out of luck (unless you want to use the Fusion style, which sort of negates one of the strengths of Qt which is its native look). Elvis > > Thanks, > > Marcus From jcfr at kitware.com Fri Aug 31 14:21:18 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 31 Aug 2018 14:21:18 -0400 Subject: [vtk-developers] [vtkusers] the New QVTKOpenGLWidget In-Reply-To: References: Message-ID: Hi All, Thanks for the feedback. Based on feedback, we will keep the widget QVTKOpenGLWidget and only rename QVTKOpenGLSimpleWidget to QVTKOpenGLNativeWidget The corresponding change can be found at https://gitlab.kitware.com/vtk/vtk/merge_requests/4642 > unless it's somehow possible to make a widget that will work well in both scenarios That is the idea, ultimately we would like the QVTKOpenGLWidget to be smarter. Thanks Jc On Tue, Aug 28, 2018 at 1:28 AM Elvis Stansvik wrote: > 2018-08-28 0:12 GMT+02:00 Jean-Christophe Fillion-Robin >: > > Hi All, > > > > To follow up on Mathieu email, we are in in the process of integrating > this > > merge request [1] (and the equivalent in paraview [2]) that will > add/rename > > the following classes: > > > > * QVTKOpenGLAlienWidget (equivalent to QVTKOpenGLWidget class described > in > > the previous email) > > > > * QVTKOpenGLNativeWidget (equivalent to QVTKOpenGLSimpleWidget class > > described in the previous email) > > > > * QVTKOpenGLWidget will: > > - behave as it was before the introduction of the "new > QVTKOpenGLWidget" > > and will instead derive from QVTKOpenGLNativeWidget. > > - only be available if VTK_LEGACY_REMOVE is OFF > > - will most likely be removed in VTK 10 > > > > > > We anticipate that this clearer naming convention will facilitate update > of > > user code. > > > > Let us know what you think, > > I think this naming is the best one possible, unless it's somehow > possible to make a widget that will work well in both scenarios of > course :) > > Much better naming than the "Simple" suffix, so +1. > > Elvis > > > > > Thanks > > Jc > > > > > > [1] https://gitlab.kitware.com/vtk/vtk/merge_requests/4625 > > [2] https://gitlab.kitware.com/paraview/paraview/merge_requests/2693 > > > > > > > > > > > > > > > > > > On Thu, Aug 23, 2018 at 5:07 AM Mathieu Westphal > > wrote: > >> > >> Hello list, > >> > >> If you are working on a VTK/Qt application this information should > >> interest you. > >> Sometime ago, a new QVTKOpenGLWidget implementation has been added to > VTK, > >> while the old one has been moved to QVTKOpenGLSimpleWidget. > >> The last fixes for this change have just been merged, so make sure to > use > >> VTK master to test this. > >> > >> 1. Why is there a new widget and what does it do ? > >> We have been having some issues reported for the old widget, and the old > >> widget could not support quad buffer stereo rendering by design. > >> Has it is a needed feature in ParaView, a reimplementation was > necessary. > >> This new widget fix most of the reported issues with the old widget as > well > >> as adding stereo support. > >> > >> 2. Why keeping the old widget around then ? > >> Due to Qt limitations, this new implementation does not support very > well > >> being a native widget. > >> But native widget are sometimes mandatory, for example within > QScrollArea > >> and QMDIArea, so the QVTKOpenGLSimpleWidget should be used when in > needs of > >> VTK rendering in the contact of Qt native widget. > >> > >> Also it allows users to switch back to the old widget if necessary. > >> > >> 3. I'm not sure what native widgets are, what should I do in my > >> application ? > >> > >> Here are the different situation : > >> > >> Your Qt application only uses a central QVTKOpenGLWidget for rendering: > >> -> Nothing to do, just build with last master and make sure all is > working > >> well > >> Your Qt application only uses QVTKOpenGLWidget within QScrollArea or > >> QMDIArea, or manually set widgets to be native and you are not > interested by > >> stereo rendering. > >> -> Change all your QVTKOpenGLWidget to QVTKOpenGLSimpleWidget and you > are > >> good to go > >> Your application uses a non-native QVTKOpenGLWidget for rendering as > well > >> as native QVTKOpenGLWidget for rendering (eg: ParaView, with the central > >> rendering widget and the color map editor rendering widget in scroll > areas) > >> : > >> -> Use QVTKOpenGLWidget for non-native widgets and > QVTKOpenGLSimpleWidget > >> for native ones. The later will never support stereo. > >> > >> > >> 4. I followed your recommendation but I see some strange > >> stuff/bugs/rendering issues > >> Even if this new class has been tested extensively and will be used in > the > >> next ParaView release, It may still contains some issues. Feel free to > >> discuss them in this mailing list or on our gitlab. > >> > >> Best regards, > >> > >> Mathieu Westphal > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the VTK FAQ at: > > http://www.vtk.org/Wiki/VTK_FAQ > > > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > > > Follow this link to subscribe/unsubscribe: > > https://public.kitware.com/mailman/listinfo/vtkusers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: