Skip to main content
16-Pearl
October 9, 2025
Solved

ThingView Widget – Slow PDF Rendering Compared to WebFrame Widget

  • October 9, 2025
  • 1 reply
  • 341 views

Hi everyone,

I’m facing a performance issue related to PDF rendering between two widgets in ThingWorx.

We are using a Repository Connector (not a local FileRepository) where all PDF files are stored.
Each PDF is around 4 MB in size.

 

When I render a PDF through a WebFrame widget, it loads almost instantly (within a second).
However, when I render the same PDF using a ThingView widget, it behaves differently:

 

  • The first PDF usually loads quickly.

  • But when I open subsequent PDFs, the loading time increases significantly (sometimes up to 8 seconds or more).

It feels like ThingView is reloading or re-parsing the file differently each time.

 

Additional Note:
I have also tested the same setup using a local FileRepository, and the ThingView widget works perfectly fine there. The performance issue seems to appear only when using the remote Repository Connector.
What’s confusing is that the WebFrame widget still loads the same remote PDFs much faster, so I’m trying to understand why the ThingView widget behaves differently in this case.

 

Note:
We are currently using the WebFrame widget, but would like to switch to the ThingView widget because, on iPads, the WebFrame only displays the first page of the PDF and is not scrollable. The ThingView widget, however, displays all pages correctly.

 

Thanks,

Best answer by MA8731174

Hi @TonyZhang According to article CS455073, the problem is resolved. The ticket was created by me and its now working as expected. I wanted to use thingview widget because webgl widget could render the pdf in mashup in IPADs but now i have found a solution for that also as i use now downloadLink and can also read that either the file is opening in mobile device or PC and navigates accordingly. 

 

More about the problem and solution to the issue : https://community.ptc.com/t5/ThingWorx-Developers/WebFrame-Widget-only-shows-first-page-of-PDF-on-iPad-Body/m-p/1055801#M71236

 
 
Thank you

1 reply

MA873117416-PearlAuthor
16-Pearl
October 9, 2025

Update – Further Diagnosis

After additional testing, I can confirm that the issue is not related to the Repository Connector or remote access.
The behaviour is actually linked to how the ThingView widget is placed and reloaded in the mashup.

Here’s what I observed:

  • When the ThingView widget is placed directly in the same mashup where I select the PDF file from a grid, everything works perfectly.
    → The file renders correctly each time I select a new entry from the grid.

  • However, when I use a separate mashup that only contains the ThingView widget, and open that mashup as a modal popup, things behave differently:

    1. The first file loads and renders correctly.

    2. When I close the popup and select another file from the grid, the modal mashup opens again — but this time the PDF does not render.

    3. I can still see the correct file path in a Label widget inside that modal mashup (so the parameter is definitely being passed correctly).

This means the path binding works fine, but for some reason, the ThingView widget does not re-render or refresh when the mashup is re-opened as a popup.

💡 The same logic and data bindings work perfectly when the widget is part of the main mashup, but fail when the widget is inside a modal popup mashup that gets closed and reopened.

Has anyone experienced similar behavior where the ThingView widget doesn’t refresh when reopening a popup?
Is there any way to force the ThingView to reinitialize or reload when the mashup is reopened?

Thanks again for your help!

MA873117416-PearlAuthor
16-Pearl
October 10, 2025

@TonyZhang 

Yes, I tried by assigning a hardcoded PDF URL to the ProductToView property. It works correctly the first time, but when I close the popup and open it again, the PDF no longer renders.

A support ticket has already been created for further investigation. Please let me know if you need more details. Thank you

16-Pearl
March 11, 2026

According to article CS455073, looks like this issue is corrected in Windchill Navigate 10.1