Latest Contributions by mgeorge

Hi Matthew Barr‌, basically it's as Robert Scheitlin, GISP‌ has said. For more information see https://community.esri.com/thread/237519-sketch-and-measurement-graphics-not-showing-up-after-412-update. We are currently tracking this issue and working on a possible workaround for drivers that cannot be fixed. ... View more

Hi Denis Pokotylyuk‌, I can't give any promises, but we are currently working on this and want to have clustering in some form by 4.14 (I.e., at feature parity with 3x). There have been some exciting server/service advancements that we want to leverage in 4.x where we can. In fact, I just got out of a meeting on this very topic. By the way, if there's anything new you'd like to see in terms of clustering, please let us know! ... View more

Kalyan Singh Rathore‌ for VectorTileLayers, are you running into this issue in 4.12? If so, on which basemaps? I know we had this limitation in 4.11, but I believe some work was done to remove it in 4.12. ... View more

Hi Kalyan Singh Rathore‌. We're aware of this issue and are currently working to improve the visual quality and rendering performance for these types of raster basemaps, however, I'm not sure if this will be done in time for next release. This visual issue is exasperated when the `devicePixelRatio` for a given device is not 1.  For now, we recommend using vector basemaps that should not suffer from this problem. ... View more

David Tshamussa‌ if you are still experiencing issues, this may be related to Sketch and measurement graphics not showing up after 4.12 update. Do you know what graphics card your machine is using?  ... View more

Hi Shakil Choudhury‌, do you know what graphics card your machine is using? This seems related to https://community.esri.com/thread/237519-sketch-and-measurement-graphics-not-showing-up-after-412-update  ... View more

Hi everyone, just wanted to give another update on this. After looking at a machine with an Intel HD 3000 graphics exhibiting the same issue, we were able to narrow down the problem as relating to texture lookups. The specific 4.12 change that caused this rendering issue was a 2D engine-level performance enhancement to speed up pushing attribute changes (as mentioned earlier). Basically we encode binary flags into the red channel of a texture, and then decode this on the GPU to drive visibility, filters, and effects. As part of this, we were able to normalize the way we send per-feature data to the GPU, allowing multiple vertices to reuse the same texture data.This is both faster for us to update, as well as alleviates how much GPU memory each vertex requires. Related to this graphic visibility issue, we noticed a similar problem for FeatureLayers where inaccuracies in the decoding process on our device was causing `FeatureFilter` and `FeatureEffect` to corrupt each other. At least for the specific device we have access to, it appears that sampler precision specifiers are being ignored. This does not appear to be in compliance with the OpenGL ES Specification which stipulates that these specifiers should drive the precision of the result of `texture2D` (see section 8 of the OpenGL ES 1.0 Specification). This causes the bit flags to be decoded incorrectly. If possible, we recommend updating graphics drivers, but we are currently working on a driver mitigation workaround that should prevent hard failures like visible features/graphics becoming invisible. ... View more

FYI, we recently added a client-side FeatureFilter which provides a fast way of hiding/showing features based on an attribute.  ... View more

Roel Garcia‌ maybe a FeatureFilter would fit your use case? Example usage here: https://developers.arcgis.com/javascript/latest/sample-code/featurefilter-attributes/index.html ... View more

Thanks everyone for the feedback. We'll update you when we have more information. Currently we're in the process of getting access to a device with the issue. As ntpc iland‌ mentioned, it may be a good idea to try updating the graphics drivers on the affected machines and see if this fixes the problem. ... View more

For those who are experiencing this problem, do FeatureLayers also suffer from the same issue? Or is this issue just with sketch/graphics? To give a little insight into this issue, in both 2D and 3D we use WebGL to do all of the rendering, however due to the different nature of the rendering requirements, these code execution paths are different. For 2D we recently added support for fast-attribute updates, which allows for quickly changing things like the valueExpression of a visualVariable, and as a result of this change, visibility, filters, effects, and other per-feature/graphic attributes also now go through this faster code path. We have several fallbacks for when devices do not support certain features (like SharedArrayBuffer or the WebGL floating point textures extension), however sometimes these fallbacks are not enough when we encounter driver related issues. We'll need to do a little digging to see where the problem lies. ... View more

Hi Weslly H., Thanks for reporting this. On the affected HP machine, can you post the DirectX diagnostic report? Press Windows Key + R, type in DxDiag, click Save All Information Matt ... View more

Hi Kevin C‌! You might want to try out the new FeatureFilter we added in the last release. This allows you to specify a where clause/geometry expression/etc. and filter out everything but those features. Seems like this might be an easier way to accomplish what you are trying to do. We also added (in beta) the ability to specify a FeatureEffect that will similarly change the styling of features that pass or fail the effect's filter (for instance, you could gray out features that don't pass the effect's filter). ... View more

Hi Axelle Ribault‌, In 4.11 we don't yet have support for passing in user-specified WebSocket connections, but you can use GeoEvent server to create a Stream Service. ... View more

Hi Tyler Kirk Since migrating to WebGL, implicit internal limits for the size of various properties were added - this was done to conserve memory. For rendering markers, we extrude a quad (based on symbol size) and then translate each vertex of that quad based on the x/y offset of the symbol. We then encode this information into a single signed byte per component. That means that the final range of the value (the relative vertex position after translation by the offset) must be +-128 (px) or there may be visual artifacts. This means that the allowable range of values for x/y offsets is unfortunately a factor of the size of the symbol, at least for now. This is not very clear, and we want to be more explicit about these limitations going forward, clamping and logging warnings when exceeded. Additionally for cases like x/y offset, we would like to potentially modify the rendering logic to instead have hard limitations that are independent of other properties, so that it is easier to know when they are being exceeded. In general, we don't find many use-cases for offsetting symbols by such a large amount -- typically x/y offset are used to adjust the anchor point of a marker with respect to their image, so we would expect the x/y offset to be less that than size of the marker. Is there a specific use-case you are trying to use the x/y offset to achieve? ... View more